I have a very minor issue with it:
The API endpoints naming scheme. /greet.Person seems quite unusual - wouldn't something like /greet/person/abc be better?
Show HN: Encore – Go framework for building distributed systems
11–20 of 71 posts
Re: Show HN: Encore – Go framework for building distributed systems
#12This looks neat, but man. I'm not a fan of code generation magic. It's part of the reason I moved away from the Rails ecosystem - even though I knew what Rails was doing under the hood, the magic started to give me the heebie-jeebies. Maybe I'm weird, but I'd rather spend 10-15 minutes writing some boilerplate for a service and control the code than trust a third-party tool to do it for me. I also feel like this is d…
I agree regarding magic, but I've struggled to find the balance because if you have copy/pasted boilerplate, it's much harder to upgrade major versions because you have a lot of stuff to update/review. If you've modified the boilerplate, it may be impossible.
How do you balance that?
Re: Show HN: Encore – Go framework for building distributed systems
#13This looks neat, but man. I'm not a fan of code generation magic. It's part of the reason I moved away from the Rails ecosystem - even though I knew what Rails was doing under the hood, the magic started to give me the heebie-jeebies. Maybe I'm weird, but I'd rather spend 10-15 minutes writing some boilerplate for a service and control the code than trust a third-party tool to do it for me. I also feel like this is d…
Thanks for the feedback. I think there are many different types of magic. In my (biased) opinion I think the code generation we do is much more on the side of "how to do this is obvious but annoying" rather than on the "I don't know what's happening" side.
As for platform vs framework, my realization is that the traditional separation of frameworks/libraries from infrastructure means that it's almost impossible to improve many parts of the developer experience.
The annoying parts of building backends and distributed systems come from the integration between the two. Setting up databases, secrets, and so on all require bridging that gap. Another big area that we're investing in is providing insights about how your application works at runtime, in production, directly at your fingertips when you're writing code. That's also not something you can do without integrating across that gap.
As you pointed out in the edit, you can absolutely use Encore with your own cloud. We're working on making the deployment options much more flexible, but it's very much not another "let's make an infrastructure tool and then charge a premium on top of your cloud bill to manage it for you".
Our business model is much more about aligning the incentives with the developers. We want to provide the best developer experience out there, and by charging for that as opposed to for infrastructure, we'll happily invest time to reduce our users' and customers' cloud bills, rather than just selling them more servers they don't really need.
Re: Show HN: Encore – Go framework for building distributed systems
#14I have a very minor issue with it: The API endpoints naming scheme. /greet.Person seems quite unusual - wouldn't something like /greet/person/abc be better?
It's like gRPC in the sense that it's endpoint-centric rather than URL-centric.
Re: Show HN: Encore – Go framework for building distributed systems
#15Is it possible to integrate this with event based systems or message queues or is encore not made to be integrated into existing service landscapes anyways?
Re: Show HN: Encore – Go framework for building distributed systems
#16I have a very minor issue with it: The API endpoints naming scheme. /greet.Person seems quite unusual - wouldn't something like /greet/person/abc be better?
It's like gRPC in the sense that it's endpoint-centric rather than URL-centric.
At least for a public facing API i would like some more customization possibilities, but this can maybe be done with a seperate BFF / API Gateway / GraphQL gateway etc. Thanks for the answer.
Re: Show HN: Encore – Go framework for building distributed systems
#17This looks pretty awesome! I'd love to see an example using websockets. I've used Go for websockets in the past but find the boilerplate-to-custom code ratio isn't great. Knowing Go has a solid webrtc library ( https://github.com/pion/webrtc ), another cool feature would be webrtc support. Tons you can build with that!
Thanks! Encore does support dropping down to plain HTTP requests which lets you use Websockets, see [1]. We hope to make it more ergonomic and less boilerplate-y in the future, but it is supported :) [1] https://github.com/encoredev/examples/tree/main/websocket-ec...
Good to know! Thanks for the example. Looking forward to giving this a spin!
Re: Show HN: Encore – Go framework for building distributed systems
#18Is it possible to integrate this with event based systems or message queues or is encore not made to be integrated into existing service landscapes anyways?
Since Encore supports deploying to your own cloud, it's definitely possible to integrate with existing systems you already have in place.
We're also working on expanding the set of infrastructure primitives supported, so that you get the Encore experience for doing more types of things. Things like Pub/Sub and message queues are the next things we'd like to add support for.
Re: Show HN: Encore – Go framework for building distributed systems
#19I kinda like this a lot. Raw SQL in the examples. And generated and consumable api services. I will surely play with this later.
Re: Show HN: Encore – Go framework for building distributed systems
#20Looks pretty cool! Couple of questions:
- Is there a story behind the name?
- Out of curiosity, does “Encore Cloud” also run on AWS?
- I think a lot of developers have a mentality of “rather write boilerplate than be tied to a platform not endorsed by $bigCompany”. Do you have a strategy to mitigate this?