Hacker News Reader

In my experience you can achieve a lot with FaaS - but you still need an API, database and storage - which Netlify Functions doesn’t offer out of the box. I have a couple of sites deployed on Netlify with a ‘serverless’ backend deployed to AWS separately.

Their functions are also limited to triggers relating only to Netlify events: https://docs.netlify.com/functions/trigger-on-events/#availa...

> Their functions are also limited to triggers relating only to Netlify events

to be clear the functions are also exposed to the public internet as http endpoints so you can ping them from anywhere else, including, for example, your frontend app, or Zapier [1], or GitHub Actions or cron service of your choice

(i work at netlify)

1: https://www.netlify.com/blog/2018/11/07/automate-your-netlif...

Netlify is glorified S3 + Cloudfront hosting.

They did a very good job at marketing "HTML5 hosting"

It's glorified in the sense that it's much cheaper. I have had small sites on s3 plus cf and have gotten a bill that boggles the mind because I could be hosting the content for free on netlify.

As someone who is currently hosting a static site with S3 + CloudFront, I'd be interested to hear more about this. Were you hosting something more heavyweight than mostly text?

Make sure that you've set the correct cache control headers on the S3 objects. So "Max age" should be something far future for static assets and something near future for HTML files.

If you forget that then Cloudfront will retrieve the objects from S3 every time there is any activity on your site and your bill will go up really fast.

This is precisely why netlify's offering is valuable. It works out of the box with zero config. If you're using a common static site generator you don't even need to setup the build process, just give it your git repo, and push when you want to deploy.

That's not really a compelling reason when it's literally a single input field on a form to setup. Also, if you're in the business of web development, HTTP cache control headers are something you should know about regardless.

As with a lot of AWS, it's easy if you know you need to do it, but there are a lot of gotchas which can be very expensive if hit (and there's no way to limit expenditure).

Any devs out there with a Visual Studio/MSDN as subscription should also be aware of their free Azure credit. I get 50$/Mo, which is more than enough to host a static site with CDN (my blog typically runs at around 1-2$).

> I get 50$/Mo

For how long? I remember I got something similar for AWS for a year. Hosted my Wordpress, year passed, then prices jumped up. I migrated to Netlify, rebuilding my site as a static one, hosted for free now.

If you regularly serve bigger files but have low traffic DigitalOcean S3 Spaces and a custom Cloudflare Workers CDN might be an interesting solution for you. Cloudflare Workers are based only on requests and priced at 5$/10M and if you cache everything heavily DO’s 5$ S3 plan should be enough for most use cases. (I’m not affiliated with either company)

Check Zeit Now. You get cloud functions but you can almost architecture your code as if you were writing a monolith. Probably better as each function can be in its own language.

> Probably better as each function can be in its own language.

That sounds awful. How do you share any of your common logic? Do you have to write versions of your important routines once in each language, each with its own set of quirks and bugs?

It's bad enough in microservice land, where every time you want any shared code you have to extract it to a e.g. "utils" library and massage the versioning to get it in to the right apps.

End result: most people don't and you end up with many different little versions of your routines that do important things.

I don’t think anyone is advocating for choosing a different language per function, but rather you can use the best language for the job. For example, we have a Python monolith that has one route that is CPU-bound and would otherwise be an ideal use case for a language with real multithreading. The Python version often times out (60s) while a native Go (or perhaps Java) version would probably be on the order of a single second.

In our case the limitation is less about the monolith architecture and more about our team’s unwillingness to learn a new language.

> a Python monolith that has one route that is CPU-bound and would otherwise be an ideal use case for a language with real multithreading

Sounds nasty. The classic python answer is to try rewriting the innermost loops in cython/c/cppyy etc or try using numba/pypy.

> best language for the job

The problem with this "best ... for the job" phrasing is that there's an objectively, indisputably right answer, where I've experienced atrocious choices being inflicted upon a team under that guise, resulting in a component that nobody wants to maintain because it's foreign to everyone.

> Sounds nasty. The classic python answer is to try rewriting the innermost loops in cython/c/cppyy etc or try using numba/pypy

Yep, we’re doing this. The problem is that we’re still calling back and forth between C and Python very frequently and rewriting that next layer in C or similar is prohibitively unmaintainable.

> The problem with this "best ... for the job" phrasing is that there's an objectively, indisputably right answer, where I've experienced atrocious choices being inflicted upon a team under that guise, resulting in a component that nobody wants to maintain because it's foreign to everyone.

Fine, then let’s at least not use the wrong tools for the job, in this case, Python and language’s that impose similar tradeoffs.

> calling back and forth between C and Python

Yes - the trick really is to move your accelerated code away from python's object model, because then you can drop a lot of overhead and also release the GIL. Tricky, though. Out of interest, did you see any improvement from pypy or numba?

> prohibitively unmaintainable

I don't think well written cython should be any more unmaintainable than Go IMHO.

We didn't try numba and couldn't get pypy working; we had dependencies that didn't work with Pypy. I'm curious about numba though.

> I don't think well written cython should be any more unmaintainable than Go IMHO.

I've written a lot of Go, it's always struck me as about as maintainable as Python (I would put it at a bit more maintainable than Python given its mature static typing story--mypy still has lots of problems). I haven't given Cython a fair shake, but it doesn't seem very well-invested in; this is generally what has kept me away from it.

This. Or maybe you need a dependency that is not available in your main language.

You can, but you don't have to. Each route is built separately but it can all be a single monolithic app underneath.

You can also pair with something like firebase, userbase, etc.

> but it seems like you still need a backend

Of course. It's just managed by someone else and you often are paying per usage. And you'll find yourself needing to wrangle numerous serverless platforms to actually build out relevant business logic if you want to do something meaningful, one third-party microservice at a time.

> Also, because it's just a static site, there's no backend or database, so you get better security.

It's not as trendy to think of it this way, but "static sites" are just caches with manual invalidation.

It might be more expensive in the long run, but it's an operational expense rather than a capital expense, which I would argue most software projects are.

You typically hook up changes in your data with static site rebuilds.

Thinking of it as a cache has some merit, but it is more exciting to think of it as a event driven system as a whole, where instead of triggering a render on demand (user wants to look at something) you trigger it when a change happens.

This pattern reduces the need for ad hoc caching and eliminates some accidental complexity as well because it reduces the coupling of management and representation.

They are only if you make them that way.