Time to Go?

I want my new project to follow microservice architecture (whatever that means) like I said in my last blog post. There has been some slight changes in my project since that. I still have that first service (authentication) made with Spring Boot up and running but most likely that is going to be the one and only service made with Spring Boot. I still don’t like all the abstraction in the authentication process. It just makes me confused and I haven’t had the time to try and undestand what is happening and why. But that is not the main reason why it is probably the only Java service. Even barebone Spring Boot apps tend to eat a lot of memory (anything between 200mb to 1gb). That is a big no-go because of my very limited resources (just one Digital Ocean droplet). Enter Go.

But a lot has happened in the last couple of weeks, though. I have made my very first CRUD app with Go(lang) and I am pretty excited about it. It didn’t actually take more than a couple of days since it is very basic CRUD app. But it is exactly what it needs to be. Only “special” thing about it is that it authenticates against the Java service with JWT via HTTP calls. And the best part is that since I got that up and running it’s a lot easier to make the other three or four services with Go since they are basically the same. CRUD functionality with authentication. Why? Keep It Simple Stupid.

I’m just starting to get into Go and I really like it so far and I’m hoping that it gets even better when I understand it a bit more. So far so good. One of the biggest things that I haven’t found out is that what is the project structure supposed to be like. At the moment it’s not that big of a deal since my services are going to be very simple, though.

Last night I ran into a Go framework called Buffalo. It seemed a lot like Django for Python (which I liked) and made me pause for a moment to decide whether to use it or not. Ultimately I decided not to. It would just add great deal of abstraction and unneeded stuff for my simple services even though it might make the development process a lot faster. But it is intriguing and I might try it out when I have time for that (like redo this site [again]). The simplicity of my services is also the reason why I opted out of using ORM, too. I’m positive that it would make development faster and my life possibly easier but again it would add layer of abstraction that I do not need. Great thing about this microservice architecture (or just service oriented?) is that I can decide to use Buffalo or ORM or similar to a service where it is needed/useful.

While we’re talking about Go I have played Pokemon Go almost for two years now. Awesome, isn’t it?


Leave a Reply

Your email address will not be published. Required fields are marked *