Webiny-js: Question: How to not use Serverless

[theluk]

Hi there,

first of all, congrats to your success and major release.

We started few weeks ago development using webiny and we are trying to slowly migrate a huge website to the cms. Now we talked already that the major release will come soon.

Now we run into a kind of an issue: We started using webiny, because even though it was built on lambdas, we were still able to run in using just a simple express server. The same way we also wanted to deploy our app, as we are not interested in serverless, in a old monolithic fassion.

Now the new release seems like it is more of a lock-in into serverless and/or aws.
If not, I would be more than happy if you could provide some information, how the api(s) could be run on a single managed server, as it was easily possible before.

Thanks in advance, and best of luck!

[theluk]

would something like this be possible?

https://serverless.com/blog/fn-project-serverless/

as far as I understand, fn is a runtime or a scheduler for lambda functions and serverless seems to have a integration for that, so, if necessary, we could run the new serverless stack still on premise?

Do you think that might work and if yes, what would we have to think about? E.g. you seem to be using aws cognito, is there any useful alternative to that?

[Pavel910]

Hi @theluk, great to see you still hanging around :)

Let me try to clarify our goals and strategy:
our only deployment direction is serverless (as a concept, I'm not talking about Serverless Framework here) on cloud providers like AWS, GCP, Azure, etc. At this point we only support AWS - yes, but that's not where we stop. Multi-cloud deployments are one of the primary goals on our roadmap, so developers can decide which part of Webiny goes to which provider. However, this is not going to happen over night, so the plan is to dedicate a good part of 2020 to research and development of that.

Webiny was never meant to be hosted on express and VPSs. Great job on managing to do that, but that was never our intention to support officially.

Regarding serverless (as in Serverless Framework):
we're not using the Framework itself, only their Components. This concept will allow us to later support multi-cloud deployments. There is no lock-in in particular, as those components are not a "platform", just the tool to make deployments more enjoyable. And on top of that, we're not even using the serverless CLI, instead we've built our own layer (a very simple one) on top of the Components to better suite our needs.

You can find all our components here, in the components folder. Some of them are AWS specific, others are meant to later support different cloud providers.

Regarding monolithic: that's exactly what this system is NOT any more :) Each small service (pageBuilder, security, i18n, files, ....) is now deployed separately into its own function, behind its own API Gateway and after that its all connected into a GraphQL API using Apollo Federation.

Cognito:
Our security doesn't do anything regarding authentication, it relies on plugins. By default, we've created a set of plugins to work with Cognito. That can easily be changed by implementing your own auth plugins, here are the references:

• api-plugin-security-cognito
• app-plugin-security-cognito

And then you simply replace the plugins to deploy, as shown in the example here.

Regarding the Fn Project, it is for Serverless Framework which operates on CloudFormation (unlike the Components which use the cloud provider's SDK directly). I cannot speak for that, as I've never tried it.

I'm sorry if you find our vision unacceptable for your projects, but that's how things are :)

If you need any more info regarding anything, please, do ask :)

[kisg]

Hi,

I just stumbled upon Webiny, and I am very excited about the project.
I think, that you made a great choice with the "serverless" architecture: it will make sure, that Webiny stays scalable and clean because you cannot take "I just throw this local hack in here for now" type of shortcuts.

Regarding the deployment: I think there is an important middle ground between a monolithic deployment and a cloud-based serverless deployment: a container-based deployment on Kubernetes. (There are other container runtimes out there, but Kubernetes is the de-facto standard.)

It should be fairly straightforward to package each API component into a Kubernetes image and deploy them to a Kubernetes cluster, where the other necessary interfaces are also deployed, e.g. a database or a S3 compatible object storage, like minio.

With this solution Webiny would instantly work in environments where a public cloud deployment is just not acceptable (company policies, security clearances ... etc.). This would also allow an offline development environment with a simple minikube VM on the local machine.

What do you think? Would you consider accepting contributions that enable such a container-based deployment?

Best Regards,
Gergely

[Pavel910]

@kisg contributions of any kind are very very welcome, and we can also provide you with help and directions along the way. However, at this moment, we don't have enough resources to dedicated ourselves to Kubernetes deployments, nor do we have an expertise in that area.

FYI, we're now working on the documentation site, and we'll soon publish the Deep dive section which explains all the inner details of Webiny architecture, deployments, etc. I think it will greatly help you if you decide to try to adapt Webiny for Kubernetes yourself.

Let me know if you need some help or information :)

[theluk]

Thank You for the answer, which seems disappointing.

So, is it correct, that in the current release

1. the deployment is possible only on AWS
2. there is no way to run anything of the current version purely on a local machine

[Pavel910]

@theluk correct! Only React apps can be run locally, but the API must be deployed to the cloud.

[theluk]

But... why? I do not understand the decision behind this, this does not seem in any way to be an industry standard, or a commonly used thing. At least I never heard or saw anything like that. For everything I know in the web development industry there is a local development tooling available.

I mean how is the development process on API related stuff? I change something and then it is deployed automatically within seconds or do I have to do the full manual deploy process?

[Pavel910]

One of the biggest reasons behind this is you can't simulate a full range of any cloud provider's services locally. As soon as you try to simulate any serious service locally, like SNS, Lambda triggers and basically the entire AWS or GCP or whatever - it is nowhere close to real cloud environment which means it is not reliable. How can you be sure that your simulation will work exactly as the real thing? Can you simulate API Gateway timeouts, or number of requests limits, or bucket creation/deletion concurrency? Those are real problems and no local environment can reliably simulate those.

Our Files service uses S3 events to trigger file cleanup when a file is deleted, in a 100% async cloud-native way. You can't even begin to test that locally, since S3 can't trigger a lambda that sits on your local machine.

So yes - it is not YET mainstream, but it very soon will be, with more and more companies turning to cloud services and serverless. And deployment speeds will become faster and faster so it won't bother you if you have to redeploy every minute.

As to local development: in case of GraphQL API you have to turn to TDD, and implement tests on your schema like in this example on our repo. This way you test your API without deploying it. At this point the deploy of the entire Webiny takes about 3 minutes (on subsequent deploys, not the first one). Sounds horrific, right? As it turns out - it's not such a big deal. You don't deploy after each line of code :)

We believe it will be mainstream, and we've taken the risk to be at the forefront of the movement together with the amazing team at Serverless. Let's see where it goes :)

[theluk]

well as a web developer, not a devops engineer, I do not care so much about the things you describe in the first paragraph. Also, until now, nobody really tried that what you describe locally. As I understand it you are talking about infrastructure, and partly I do understand that there are things you cannot properly simulate. But that has nothing to do with a local development environment. During a simple server running a graphiql and apollo server I do not care about triggers, SNSs, buckets, request limits, timeouts or any of those infrustructure issues.

you can install kubernetes+kubeless or fn locally and that matches almost 100% a perfect lambda environment. Even serverless had it (not components) that you just switched a different provider or even used the offline plugin and tadaaa you were running locally. I think mainstream, if serverless at all, will still try to run locally if possible.

[kisg]

@theluk From their above answers, I think that the Webiny team is open to patches that enable deployment on Kubernetes. So I don't see this as a showstopper, just something that is not in focus of the core team for now. As you wrote, it should be straightforward to set up a Kubernetes cluster with minio, kubeless or another lambda runtime. This includes minikube for a pleasant local development experience.

[theluk]

It's definitely not a showstopper. As said before, the whole thing is great work, all the CMS, page builder, simples plugin system, react, cra, graphql, what do you want more?

What might be solved differently is the way of starting / running things. Now many of the startup/server logic is in serverless components, which, if you do not want to use them, you need to reimplement a lot of stuff by your self. Which, honestly, we will do, because there is no other system with similar features. We have a lot of components which are mainly pure so we can almost plug and play them into the page builder which is great.

Currently, we are almost fully compatible with the current master, but we are not able to run the whole thing, because it uses AWS and Serverless and many different services. So in the previous version we started 1 simple webserver, that run the api and the rest were in our setup just static cra builds. Gorgeous! There was no magic in it. Now, we will have to invest I guess like 2 or 3 weeks to a) understand serverless components b) understand webinys custom components c) implement @serverless/function to support FN or something else, d) reimplement everything webiny is doing in order to push stuff to s3 and run stuff on lambda. So a lot of steps that we are not experienced with.

That's the only reason why I am just disapointed. But don't worry, we will share all progress.

[Pavel910]

@theluk regarding the components that deploy GraphQL services, once you do a deploy, all the source code is available in the api/.webiny folder. If you go through those folders you will see that there isn't much magic going on, we just hide the unnecessary boilerplate and expose customization via plugins which are passed to the component configuration.

Components simply deploy that code to a Lambda + add an API Gateway in front of it, so it can be linked with Apollo Federation Gateway.

Please send the questions you have and we will assist you in getting to know the internals of the system. The documentation will also contain all that, we're working on it as we speak :)