Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Netlify for the frontend, Micro for the backend

blog.m3o.com

Post reply on HN
Print view View original

21–30 of 66 posts

Re: Netlify for the frontend, Micro for the backend

#21

Post by cxr »

clafferty wrote: post #14

Bravo m3o, this looks awesome! Netlifys approach to static sites seemed like a no brainer since HTML is easy to host. They added lots of sugar around that to make it effortless and easy. So M3o seems like a great idea. Micro on the other hand will need some buy in but I'll definitely consider it since we use Go already. One concern is your pricing seems too reasonable (free)!

> One concern is your pricing seems too reasonable (free)!

Is that reasonable? Building anything on top of obvious loss leaders is risky. And the costs here for a year of service are either $0 on the free plan or $420 for the cheapest paid plan. There's a chasm of difference there.

I can't understand people offering platforms and services with a pitch that tries to describe what sets $THING apart from others, but when it comes to pricing, they settle for looking around at what everyone else is doing and copying that—which usually results in offering a free tier and paid plans usually starting at $5–9+ per month. Chances are, what you're selling probably isn't as unique as you think it is (this post mentions Netlify several times, for example, but Netlify doesn't only do static hosting―you can run microservices with Netlify, too, and Netlify's paid plan is cheaper).

More businesses could and should differentiate themselves in their pricing model, because the door is wide open and pretty much nobody else is showing interest in taking advantage of the opportunity.

Re: Netlify for the frontend, Micro for the backend

#22

Post by asim »

jfengel wrote: post #20

Your page doesn't show any of the backend code being deployed. I don't even know what language it's in. So it's a little hard for me to compare it to Netlify, which does have backend support in the form of lambdas, and a database in the form of FaunaDB. That's fairly limited, but it's also very easy. Clicking through to the github page, it looks like the examples are in Go... though I also see a Dockerfile. For me, I…

Thanks for the feedback. I'm assuming you mean the website. We have info and tutorial in docs but agree we could provide more clarity on the website. There is a redesign coming in the next few weeks. There are tutorials in the docs and many code examples in https://github.com/micro/services. The blog post also links to this code. But again I agree we could do more to showcase it. This post was more to demonstrate positioning of us in the market and fill the gap for those building stuff with Netlify.

Re: Netlify for the frontend, Micro for the backend

#23

Post by friendly_chap »

cxr wrote: post #21
clafferty wrote: post #14

Bravo m3o, this looks awesome! Netlifys approach to static sites seemed like a no brainer since HTML is easy to host. They added lots of sugar around that to make it effortless and easy. So M3o seems like a great idea. Micro on the other hand will need some buy in but I'll definitely consider it since we use Go already. One concern is your pricing seems too reasonable (free)!

> One concern is your pricing seems too reasonable (free)! Is that reasonable? Building anything on top of obvious loss leaders is risky. And the costs here for a year of service are either $0 on the free plan or $420 for the cheapest paid plan. There's a chasm of difference there. I can't understand people offering platforms and services with a pitch that tries to describe what sets $THING apart from others, but whe…

> Is that reasonable? Building anything on top of obvious loss leaders is risky. And the costs here for a year of service are either $0 on the free plan or $420 for the cheapest paid plan. There's a chasm of difference there.

The dev tier is free, which is a capped environment with much laxer SLAs than the production tear. Prod tier is paid.

Re: Netlify for the frontend, Micro for the backend

#24

Post by kbutler »

asim wrote: post #9
whalesalad wrote: post #6

Earlier quoted context omitted.

Heroku for sure. It’s all running on AWS so you can leverage AWS services without as much of a performance penalty for routing as say another provider. I don’t understand how this Micro framework is valuable unless your entire team writes Go. Even then, this is not just ‘micro services’ it’s a monolith on a proprietary framework that happens to have network hops between function calls. It is the kitchen sink!

All your services are written independently as microservices. In fact Micro is itself a microservices architecture and each feature is an independent service backed by highly available managed infrastructure. Yes we expect you to write everything in Go. I don't think that should be surprising since all of frontend is JavaScript, iOS is objective C and Android is Java. We think cloud is as complex Architecture as any…

> We think cloud is as complex Architecture as any of those and that requires a single language and framework for it.

Your conclusion does not follow from your premise.

Re: Netlify for the frontend, Micro for the backend

#25

Post by anamexis »

asim wrote: post #9
whalesalad wrote: post #6

Earlier quoted context omitted.

Heroku for sure. It’s all running on AWS so you can leverage AWS services without as much of a performance penalty for routing as say another provider. I don’t understand how this Micro framework is valuable unless your entire team writes Go. Even then, this is not just ‘micro services’ it’s a monolith on a proprietary framework that happens to have network hops between function calls. It is the kitchen sink!

All your services are written independently as microservices. In fact Micro is itself a microservices architecture and each feature is an independent service backed by highly available managed infrastructure. Yes we expect you to write everything in Go. I don't think that should be surprising since all of frontend is JavaScript, iOS is objective C and Android is Java. We think cloud is as complex Architecture as any…

> all of frontend is JavaScript, iOS is objective C and Android is Java

To the extent that this is true, I don't think the complexity of the architecture has anything to do with the reason there's a single language for them.

Re: Netlify for the frontend, Micro for the backend

#26

Post by rishav_sharan »

asim wrote: post #8
rishav_sharan wrote: post #7

What about the database? All these Jamstack articles always seem to skip past a db in their examples and I have never seen an "app" without an associated database. Or is the KV store supposed to act like an app database?

Founder of Micro here. Yes the key-value store is basically like a crud database. We're working on some modelling on top of that and something we'll present more like a document database. Watch this space.

Will it be possible for you folks to add a Realworld example for Micro? https://github.com/gothinkster/realworld

it will help someone like me, sitting on the fence about this whole idea, a better starting point for using Mirco for my use cases.

Re: Netlify for the frontend, Micro for the backend

#28

Post by asim »

LogicX wrote: post #27

Biggest thing for me is netlify’s distributed nature. I don’t see anything about m3o being in multiple data centers the way fly.io is. For me, that better aligns with an appropriate backend for Netlify. (Or cloudflare workers)

Big things have small beginnings. In fact, last year this time, we were a global multi-cloud, multi-region play. Because we've done it before it was fairly simple to do again but being so early in our journey it was actually more effort than it was worth. In our case now we will expand geographically as there's a demand for it and we'll put some of that control in the hands of users. If your own user base in the US or EU or Asia, you may not want your backend to be global, you may not want that cost, and you may not want to incur the issues related to distributed storage, synchronization, eventual consistency, etc and the complexity that comes with it. So I think this is something that will evolve over time. Micro builds in the concept of "Environments" and this will be the form of expansion to different regions and cloud providers. The key thing to note, we are not an edge network, Netlify wants to distribute your assets everywhere, but I think APis are for the most part centralised in the cloud with some form of geo load balancing to different regions. All of that will play out over time, so again watch this space.

Re: Netlify for the frontend, Micro for the backend

#29

Post by davedx »

mindfulmark wrote: post #15
hans0l074 wrote: post #2

When I read about such abstractions and "simplifications" (which usually end up with a 10 box diagram simplified to a 2-3 box diagram), I often hesitate to start building something new, always wondering "Am I doing this in the most " upvoted" way of implementing such a thing? Some of this tech feels like if you switch on, and stare at your monitor long enough, a "Hello World" API will be deployed on the cloud for you…

I think it's a good point and something I find myself worrying about as well. The hype around GraphQL and Apollo, for example, made me feel that I was losing serious time developing a REST APIs until I finally committed and decided to use it on a project. Obviously there ended up being a lot of trade-offs but in the end it was hard to tell if I saved any time at all. More generally, after falling for this a couple ti…

Exactly the same experience with GraphQL - indeed I think in the end it cost more time than REST. The thing is, GraphQL is a tool that really shines when you have... graph data (like Facebook). The problem is every company under the sun is now rushing to use it as if it's some kind of silver bullet because of all the hype.

Re: Netlify for the frontend, Micro for the backend

#30

Post by harrisreynolds »

rishav_sharan wrote: post #7

What about the database? All these Jamstack articles always seem to skip past a db in their examples and I have never seen an "app" without an associated database. Or is the KV store supposed to act like an app database?

This is a great point and one reason I am left scratching my head when considering building applications on the JAM stack.

We are working on a solution to this with WeBase [1] and I'd love to see us do an integration with Netlify here where you build with WeBase and host on Netlify (and get automatic API integration with your data models).

[1] https://www.webase.com

Post reply on HN