How to deploy a React app for free
blog.logrocket.com
blog.logrocket.com
Lately I've been enjoying KubeSail's (https://kubesail.com/) free tier for playing around with some SSR things. A lot of the lambda like services don't do great with doing realtime stuff since they're just meant to run one piece of code then die a few seconds later
Thanks so much for the shoutout!
Another way to handle this is by delegating the management of long-lived connections to a separate infrastructure layer. Then it's fine if the app runs/dies all the time, since it only needs to run when there's client activity. Some options are Fanout (disclosure: I'm its founder) and AWS API Gateway.
With Netlify Functions and FaunaDB (also with a generous free tier), I have a full stack web app, complete with a database, hosted for free (https://www.quidsentio.com)
According to Netlify my functions were even more resource hungry, and they were deployed to USEAST AWS region, with no way of changing that (unless you're an enterprise) — yet my API endpoint is in Europe, so they took longer to execute (~1200ms each).
Thus I finally went for the Vercel paid tier. They allow you to choose where your functions are deployed, so I've got ~300ms now. And they work better with Next.js apps, as on Netlify you have to jiggle around a bit more to get that working.
These free services are fantastic but the limitation is that they seem to be only for static sites (static in the sense that there is no data persistence).
Netlify and Github Pages, for example, are capped at 100 GB of bandwidth per month. It's a very generous cap and ample for most use cases, but something to keep in mind as your projects gain traction.
I was looking for a solution where I can host Java Spring/ASP.net toy projects easily and none of them were satisfactory
(My point being you’ll need cloud flare DDOS protection or something similar, and I’m not sure I’d classify that as “super cheap” if we are comparing against “free”.
Don’t get me wrong, Cloud run is certainly an amazing product, I love it slot. It is also cheap to run as long as you don’t run into any hiccups. However, It’s ability to generate a personal $1000 or $10000 credit card bill disqualifies it from being a good candidate for small to medium projects. It is clearly an enterprise product.
I've been using it to host project websites or single page apsp for a while and so far it turned out to be the cheapest option.
The CLI is also fairly good so its relatively easy to deploy with a CI system
This reminded me of one of my projects, http://hasgluten.com, kind of forgotten but still up & running on github pages since I learned react 6y ago.
Code is here for the archeologists: https://github.com/hasgluten/hasgluten
Read this [1] for workarounds but it's more than annoying to work around instead of just using a better hosting solution.
Personally I have only ever tried GH Pages and Netlify had no issues at all with Netlify.
>Render is a unified platform to build and run all your apps and websites with free SSL, a global CDN, private networks and auto deploys from Git.
Apart from the CDN, that's all available for e.g. Digital Ocean Droplets. But why would a CDN be needed for static websites?
It makes sense to use those services for all the additional stuff, like Netlify's offers:
>User identity, Serverless functions, Instant forms, Split testing & rollouts, Analytics, Large media
But for a basic web-app, where's the benefit?
And downloads shouldn't take too long. Basic 1Gbit connections give you 100Mbyte per second, 10M per 100mils. A landing page should be doable in 10M, and then there is at least one second left to load the rest of the page before the user can react and make a choice.
Cache only works the second time the user comes to your page. By definition, every user will experience slow loading the first time.
That said, it probably depends on your use case if it is worth bothering with a CDN or not.
They also have smart features baked right in like pre-rendering. Literally hit a checkbox and you're prerendering.
I do no see mention of size limits in the article. I just checked Firebase and the free tier allows up to 1 GiB total.
Security is the other change. To run CGI allowed control of too much for any provider to be comfortable with it. Containerization and overall Operating System improvements allow for server-side code with safety (Spectre aside).
Great article and great opportunity for anyone that wants to start small on the cloud.
With a vps, you can do front and backend and host hundreds of low traffic websites.
I don't really understand what type of developer only does front end work or where do you host your backend stuff whjen you use Vercel / Netlify?
- Maintenance (zero)
- Auto deployment
- Global CDN
- Serverless functions can deal with spikes automatically, but cost zero when idle
In fact, I understand it enough and have felt the pain enough that I am actually working on a project that will help solve several of these issues for traditional server hosting. The only thing it won't have is a global cdn but that could potentially be added in the future as well.But I think a CDN is not needed for most projects actually and my service will focus on smaller to medium sized projects.
https://deployjs.com/ - but it's pretty far from even reaching an alpha release :)
It's configured to auto deploy from GitHub every time I merge to the "master" branch.
Works pretty well for my static site and it's free because I'm a solo founder therefore there's only one team member.
The Logrocket blog is an excellent example of this. Lots of useful blog posts. Another one I've been relying on is the blog of Robin Wieruch [1].
I guess stating this is a little obvious, but one of the upsides of using popular tools is the productivity boost you get from the surrounding ecosystem.
But here is some advice from an old programmer: once you start making bigger and more complex projects, you will start to make your own convenience libraries. And soon you will realize that you've built your own React-like library. But only less stable and less well thought out, because react has the huge community and maturity.
But if you only do some small functionality, or something specific with the technology, vanilla is perfectly fine.
However, if you are a single page app coder, I would definitely go for something like React.
If fact, huge projects are likely to suffer from using React, because virtual DOMs get out of hand and a lot of resources a wasted by building and rebuilding VDOM and looking for the changes.
Also, for some reason, React brings a lot of cargo-culting. Many don't stop to thing whether they should even if they can. They bring React, then they bring Redux, then all the rest is being dragged in and you get multi MB bundles for some truly trivial purposes. Of course, that's more on developers than on React, but it happens way to often. And for some reason just bringing React and Co. is not enough, it usually ends up in some imressive architecture astronautics. At the end you have a project that is big, but slow and still impossible to understand because the levels of indirection are off the charts.
The sentiment that everybody reaches for Redux is tired, in my opinion. After following many in the web development community and keeping up with online forums such as this, it's fairly clear to me that people have moved on from the heavy armor previously associated with React if they have a choice. For instance, people learned that they were using Redux for prop drilling, which led to many switching over to the context API natively from React. Another good example is Gatsby, for those who realized they have a static site and would like to address the SEO issues associated with a SPA.
Also, a lot of times, companies adopted React and Redux before the inception of these new, more powerful libraries that are obvious choices on the ground as of August 2020. But, have fun refactoring your entire client side state seamlessly if you're tracking state more sophisticated than the status of the application sidebar.
1) That React is a powerful, productive, ergonomic language
2) That high quality resources exist for using it
I have struggled with both of these in React, yet in vanilla JS and html canvas I have no problem writing a 3d graphics engine lol
The last one I dropped was https://www.robinwieruch.de/web-applications which has more than 5000 words (1/6 of a book) of fundamentals in web development -- which took me 3 workdays of writing without anyone paying me for it. Still it gets less attention on Twitter than some random dev meme or inspirational dev tweet; and will probably not be picked up by HackerNews if anyone posts it ¯\_(ツ)_/¯
I do my best to teach people fundamentals. If they like my content on my blog, people buy my books/courses. This and their feedback (e.g. on Amazon, E-Mail) gives me confidence that I am doing the right thing. Without good content I don't get paid at the end of the month ...
Thanks for the shoutout @Pandabob! :)
It is useful, but only because react-testing-library's documentation is horrendous in this front (its documentation is fine as a reference, but not as an introduction/getting started).
However, your post will end up rotting over time as react-testing-library evolves, and will end up being old cruft spam contributing to today's issues (you search for something and find an outdated reference that doesn't work anymore).
If you really want to have positive impact with your documentation efforts, the best avenue would be to work with the software authors themselves on getting your tutorial there. And then helping to maintain it.
Of course you are not in any kind of obligation to do so. I just wanted you to think about it ;)
For sure, the easiest thing as a content creator is publishing (almost) ever green content (see web applications article). However, most often you are looking for topics that solve actual problems of your readers (see react testing library article) which often leads to bleeding edge technology which isn't document well yet.
For what it's worth, there will always be companies with money who pay people to write content to support their products (e.g. SaaS). This makes it harder every day for individuals like me to sustain their livelihoods. However, I strongly believe in the long run quality trumps quantity.
In a perfect world, there would be (1) one perfect learning material (e.g. official documentation) and (2) one unified learning style (e.g. text, video, both) for all students. But we are not living in a perfect world and therefore people look for resources outside of the box.
I'll grant that they probably do like the idea of passing on what they know, but I very much suspect the same thing of the tech lead who was asked to write a blog post by their marketer.
Let's only allow some starving hippies to create content as of now.
Reason:
Zeit is very easy to use, you do not even need to config your workflow, and FaaS and multiple framework are well supported.
Firebase, it belongs to Google, there is no doubt Google will limit the free tier and charge you more in the next a few years.