A Simple Way to Setup/Build/Deploy React App and API on GKE/Kubernetes
adaptjs.org
adaptjs.org
With that being said, adaptjs looks interesting for more complex scenarios that actually warrant such complexity. My only gripe is that 95% of companies that use stuff like this use it to satisfy developer's desires as opposed to satisfying a real product / business need.
The hope with Adapt is that you start out with a really simple interface that looks like a PaaS/Serverless (Heroku, Zeit, adapt new/run etc.) but can be tweaked over time without having to throw out everything that was great about the PaaS. And by no means is Adapt limited to Kubernetes, it's just what is there now.
I think that a simple interface to something like Fargate/ECS with Adapt would be pretty nice as it removes the K8s complexity but handles all the container build/repo management stuff for you.
It integrates with GitHub nicely, offering deploy previews for every push and continuous deployment on pushes to master.
Their free tier is generous, too - you can set up a custom domain for each of your projects for free and get up to 300 build minutes for free per month.
Our vision with Adapt is to provide that same level of ease of use, but allow it to grow with your app. As your app grows and becomes more complex or as your app's needs change over time, it's easy for Adapt to handle those needs as well, in a way that's independent of any particular cloud or underlying infrastructure technology.
This feels like the next step up from terraform based systems.
Curious if this approach has been tried before?
"Next gen" alternatives to Terraform like Pulumi also take a different approach to similar ideas.
You might also be interested in Cloud Native Application Bundles [1].
[Update: If I'm understanding Adapt right, it looks like Adapt is going for similar ideas but doing the configuration management in JSX and attempting to automate much of the DevOps details for the end user. It sort of looks like how Create React App insulates one from Webpack for common use cases. If it works as well as it sounds in the tutorial, this could be an easier to get up and running alternative to e.g., a Docker Compose setup, for someone whose skills are more on the frontend side.]
[1]: https://cnab.io/
If you check out some of the components in adapt/cloud/src, most of them are small too, and just use other simpler components like LocalDockerImage, DockerContainer, RepositoryImage, etc.
One way to make your examples better would be to make one block of code with all the commands at the bottom or top of the page, or a link to a Makefile, so the motivated reader can copy paste everything into their IDE at once. Terraform provider docs are great for this: code at the top ... however the code is often limited to just one resource, when the user goal requires a number of resources.
It’s subtle, but declarative programming could mean one of two things: declare the systems to achieve your goal (this is how it usually works right now) or declare the goal. The latter is much better UX for devops folks because the goal is what we care about. You want to host a site, not connect a bucket to a cdn and dns. Declare the purpose, not the mechanism, and everyone saves a lot of time, because there are many micro states (implementation options) per macro state (big picture goal) (entropy 101)