
A Simple Way to Setup/Build/Deploy React App and API on GKE/Kubernetes - mv1
https://adaptjs.org/blog/2020/01/10/simple-hosting-react-app-on-google-cloud
======
transitivebs
The word simple should never be in close proximity to Kubernetes. They're
mutually exclusive when you consider the total cost of devops, maintenance,
debugging, and all the time you'll inevitably waste on things that have
nothing to do with your business' unique value proposition.

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.

~~~
mv1
I do agree that Kubernetes is too complicated an low-level for most needs,
especially for small projects. However, my experience is that while most apps
start out really simple, if they are even modestly successful, they'll
eventually need something not supported by whatever PaaS/Serverless/whatever
they've chosen for deployment.

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.

------
veeralpatel979
For anyone looking to deploy a React app, I'd _highly_ recommend Netlify:
[https://www.netlify.com/](https://www.netlify.com/)

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.

~~~
mterrel
I'm a big fan of Netlify for simple apps that don't have their own backend
API, services, etc. They've done an awesome job of making things really easy.

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.

------
sax
I love the component based approach of composing backend assets.

This feels like the next step up from terraform based systems.

Curious if this approach has been tried before?

~~~
tedmiston
I'm not familiar with Adapt before this post, but in general, yeah, a
componentized backend is a very popular approach, particularly on Kubernetes,
e.g., with tools like Jsonnet, Kustomize, Helm (umbrella) charts.

"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/](https://cnab.io/)

~~~
mv1
That is exactly the idea behind Adapt (and said better than I've been saying
it). The goal is to hide all the DevOps details but still make it easy to
customize the parts that you need to customize via JSX and React concepts.

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.

------
dang
A tutorial like this is not a valid Show HN. Please see
[https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html).

~~~
mv1
Noted

------
bionhoward
Kudos for infrastructure as code. Surprisingly many companies, particularly
database companies, don’t deliver infrastructure as code yet, which makes it
harder for their prospects to become paying customers.

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)

