Confusion about API-based application development

Traditionally, I've built applications using Ruby on Rails, rarely extracting services. I'm now moving into something more manageable and performant (SOA w/ API).

What I'm confused about is what exactly I'm losing if I build an API server in something like Go. Say I have an Article model, what would the journey look like through the system? By that, I mean in terms of ORM, controller, api, etc.

If I have an API in Go, would the ORM be on the level of the API, or could I still use Rails (which would talk to the API)? Then what about controllers? I'm lost on if this stack even makes sense:

• Go as API server
• Rails as application server

What I'm concerned about is whether I'm losing a lot of functionality that comes with Rails, like migrations, if I take this approach.

With SOA, I wouldn't really say this is necessarily Go or Ruby/Rails specific. It would be the same if you were just using Ruby or Go by themselves. What it comes down to is how your application is architected. You could do SOA with just Ruby or Go.

There are a lot of benefits to a Service Oriented Architecture.

• Clear separation of responsibility
• Different teams can work on different components
• Simplifed application archetecture code-wise
• Can lower development and management costs
• Configuration flexibility
• Targeted performance monitoring
• Simplified/gradual software updates
• Inherent service documentation (godoc generates from source)
• Targeted unit testing (does the service work?)
• Better scalability

You could probably add more benefits to that list.

The biggest obstacle to overcome is the initial planning, especially for the first time. How far do you break things down? What things should be separated? If you don't find the right balance, you can end up losing out on the benefits.

As far as how to design a SOA architecture, that really depends. If I were building a blog service with articles and comments you could have API methods like:

SubmitEntry
GetEntry
SearchEntries
GetComments
SubmitComment

The general idea is your service(s) does/do all the work. The font-end application is just a GUI. With MVC, your front-end could still have a model - it would just make API calls instead of database calls.

As far as what language to use, that really depends on you. Go is an amazing language. Its community is growing fast, but it's young. You may not be able to find a package you would otherwise have in Ruby. You may end up having to write your own. Having said that, Go has a lot of potential, and it is fun to write in!

Personal experience: The company I work for used to use PHP. A year ago we decided we needed to make a change, and we decided on Go. We have had to write a few libraries ourselves, but overall it has been an amazing year. We are now use Go exclusively (with a dash of C/C++).