A new API backend for the jamstack
blog.m3o.com
blog.m3o.com
I guess it was only a matter of time for the back end to be totally commoditized. As a UI dev, I find this pretty exciting that I have more options (serverless or building the server myself) and at what layer (IaaS, PaaS, FaaS, etc) from a variety of service providers (amazon, ms, google).
But if I was a back end dev, I would a little concerned about job security. It seems like that that career path is becoming more AWS/Azure/Google Cloud admin and less about needing to code business logic for the back end layer, especially as companies like Micro start becoming popular. From personal and professional experience, my servers tend to have little business logic and are usually a thin CRUD layer between the UI and DB layer (over-simplified, I know, but that is like 90% of the back end work I have done).
Then again, tech fads come and go and we need to adapt to the times.
I have never used any of these backend as a service but I would assume you would struggle a lot with all kinds of data processing that needs to happen on the server side?
Agreed, mostly. What I am trying to say is there is a lot of change in the back end of the stack and it's in our best interest to adapt to that change.
But if you're not willing to change, your job security will become an issue.
Agreed again, but the fact that you have the option to use Firebase at your discretion is better than not having the option to use.
> I have never used any of these backend as a service but I would assume you would struggle a lot with all kinds of data processing that needs to happen on the server side?
It depends on the use case, and that is key. Too many engineers spend too much time arguing on a hacker news that their way is the One True Way (Trademark) - that is not always the case. Your business needs should drive your tech stack choice, and no one tool is perfect.
So if, like in your example, your use case involves a lot of data processing in the back end, then the choice is easy: favor building the custom server and associated data processing yourself, over using a BaaS or FaaS. However, if you are building a CRUD app where you have like less than 1,000 people using your app, you're time constrained, you don't have enough devs, then Baas/FaaS starts to become a more viable option.
As computers become more powerful, a lot of the functionality which is reserved for the server side gets pushed to the client. The client ends up with more business functionality which helps in faster rendering, faster response. The application server's primary responsibility gets relegated to access control.
The other aspect of technology that's gradually coming to the fore is real-time communication. This enables even more business logic (in terms of access control) to be pushed to the client. Essentially, as game_the0ry mentioned, the server application gets relegated to a thin CRUD layer. And soon, maybe that CRUD layer will also go away, because the client knows excactly what is allowed and what isnt't.
As the world gets more bandwidth, more connectivity, clients become more stateful.
Conversly, this also proves that business rules are really are not that critical for businesses to function, rather it's the data behind them.
However, I don't like the name "Micro Services". It seems like the authors are trying to hijack a well established term for their brand. This might be incredibly confusing for new developers and at the same time turn off experienced ones.
Also there seems to be little explanation of the storage system. From the docs:
> State is a fundamental requirement of any system. We provide a key-value store to provide simple storage of state which can be shared between services or offload long term to keep microservices stateless and horizontally scalable.
Is key-value standard practice for the target audience? This is a little bit of a point of confusion. Especially if we're dealing with a language like Go, which has many benefits and advantages, but expressiveness is not one of them. So building up ad-hoc relational logic with it seems scary!
I'm not too familiar with Go. But from reading some of the example code[0] I get the feeling that there must be some very good reason for avoiding relational.
And what confuses me further is the name collision with go-micro[1].
[0] https://github.com/micro/services/blob/master/messages/handl...
Features are similar, especially when combined with Cloudflare Access (50 users free).
But you can’t use it commercially, right?
Micro as an open source platform enables the ability to self host, develop locally and move beyond our offering m3o.com. I think it also creates trust and thats something we're going to really be thinking about a lot in the next 5-10 years.
We're also looking beyond the core primitives themselves towards these value add services in the category of "backend", "logistics", etc. I think providing a generic platform as a service isn't good enough anymore, we really have to push a lot further.
How difficult is it to run it completely independent and on premise (i.e., define custom storage provider etc)? Any examples available? Thanks!
I think like most things you either prefer dapr's primitives or ours. As was the same with go-micro vs grpc-go.
Micro can be self hosted. It's an open source project for which you can find the docs here https://micro.mu.