Two years ago I've built for myself a small server in NodeJS - a SQLite proxy over HTTP. It's useful when you have datasets that you need to share with consumers over the network. And after a number of refactors and new requirements, now I have finally decided to rewrite the proxy in Golang for better distribution and memory efficiency. It went so well that I’ve rewritten almost everything in Go even the parts I haven't initially intended to rewrite, and now I believe that 50-70% of what I did before could be better if I used Go along with NodeJS. So, I've prooved to myself that Golang is damn efficient for any backend-heavy web development and almost equal to NodeJS in terms of dev velocity. Even creating a NAPI addons with Go is super easy compared to C++ just because of cross-compilation.
Now let's talk about one Golang shortcoming, and it's not about programming.
For the last year I mostly work as freelance dev. taking gigs and sometimes short contract work. I used Golang ocasionally, mostly when my tasks were related to blockchain, and I've even written couple microservices in Go.
Now I've looked into the job market and I am a bit dissapointed that crypto/finace domain is primary for Golang on the job market :(. And most companies require 3-4 years Go exp (even for gigs), which is hard to get if you don't work for FANG or crypto-finance field.
Golang on the job market seems like RoR for blockchain when I look at my job feeds, kind of "loked in domain language".
If smaller companies and startups also favoured Go, they could've done so many things better, and job market would look differently. I believe that Go can add more value in the products. And yes - one pet project gave me this perspective.
Talking about the pet project.
I present DAL: https://github.com/nesterow/dal
It is in early alpha, because currently only I use it. At the current stage the project can be useful for research, especially for someone who wants to write a native addon for NodeJS or wants to port their libraries to Golang, or to roast me if someone has time :)
The client part is written in TypeScript, the server can be used as standalone binary (best perf) or a nodejs addon.
Peace ✌️
Top comments (7)
Good start, but I have gone one step ahead of go and have created entity access inspired from entity framework and the syntax is lot cleaner (basically JavaScript syntax is translated to SQL) like
a.orders.some(o => o.amount > 100)is translated toEXISTS SELECT 1 FROM "orders" as o1 INNER JOIN accounts a1 on a1.accountID = o1.orderID WHERE o1.amount > 100. And it has lot of other cool features such as circuit breaker workflows etc.github.com/entity-access/entity-ac...
Nice work!
My original goal was to create a proxy, everythig else came after. The proxy uses a binary protocol so ast would complicate things in this case (client would become too fat). I picked the "mongodb approach" for query builder - which is basically parsing flat serializable structures as query parts. This approach has advantages and disadvatages, for example, the queries are json-serializable, inserts and updates can accept blobs and transfer them as binary over network, but yes - the syntax is less appealing. The builder itself covers 90% needs - everything esle can be done as raw sql query - and I can name a number of other flaws in my solution...
I can't see how this is "a step ahead of Go". In the ORM scenario you may want to check one of those Sequelize, Drizzle, TypeORM or Prisma. It's a very good exercise to try and create one of your own, though, the same way I find rewriting a project using a different language a very nice thing to try out!
Entity Access isn't just ORM, it is complete JavaScript API compiler from browser to postgres, Entity Access inspects client side query and injects security measures around the query which reduces writing business code on server side. Server side only contains entity and filter configurations. It is similar to GraphQL, but instead of GraphQL language, it uses simple JavaScript to translate queries.
Couldn't agree more. GO syntax and ecosystem is quite easy to get good at for any person with a JavaScript background, and the performance it's close to that of Rust. More focus should be on pushing GO into dev's ecosystem instead of htmx and other tooling nonsense.
Go is also quite common in companies that are building developer platforms, as well as in the infra as code world of devops.
Agreed, Go is the king in this fields - the devs know what is best for them.
I am maybe biased in my opinion about the jobs market by the search/recomendation algorithms. After all, what I see first on the job listings is a sum of different circumstances.
I just wish that more companies considered "Golang & Node" not "Golang vs Node" when they pick a stack. Replace Node with Python,PHP,etc. It's wishful thinking anyway, if something is good doesn't mean it's good for a particular company.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.