4 ms·

Anyone here have experience building a classical http Api with GO ? By classical i mean rest,json,with a sql db and a bit of business logic in the middle ? Las

by bsaul 12y ago

Anyone here have experience building a classical http Api with GO ? By classical i mean rest,json,with a sql db and a bit of business logic in the middle ? Last time i checked i found the db part lacking a bit in expressiveness ( a bit raw ), but that was half a year ago. Ps : to me, the best i've found so far is flask with sqlalchemy, and play framework in second place. But i'm bothered by the lack of static check in python and the general messy impression from scala. Go seems perfect as a language but maybe a bit limited for building a good db abstraction layer (or at least one with lots of boilerplate code removed).

voidlogic 12y ago
There are also ORMs such as sqlx or gorp. Personally, for a high performance API, I am a bit old school and I would rather for a given type Foo, I would rather write a FooDB struct that implements a FooDS interface. Everything in your app just uses FooDS. (DB = database, DS = datastore) Your FooDB implementation could be using any number of underlying technologies MongoDB, LevelDB, SQL, etc and it can change as your app changes and this change is transparent to the rest of your app (since the rest of your app uses FooDS).
- hkarthik 12y ago
  > Your FooDB implementation could be using any number of underlying technologies MongoDB, LevelDB, SQL, etc and it can change as your app changes and this change is transparent to the rest of your app (since the rest of your app uses FooDS). While this is a noble goal, when someone is building a new API or project, it's often impractical to commit to building an entire, full featured data layer in the process. Also in practice, database connectivity ends up being a fairly leaky abstraction, even if you write a database abstraction layer. Behaviors around CAP tradeoffs will bleed into your higher layers and require refactoring if you switch from one DB to another (unless you're going from one RDBMS to another).
  - MoOmer 12y ago
    For REST APIs, writing the database queries are easy enough; and, often less painful than trying to figure out an API. I don't know of any Rails app that hasn't required some amount of custom queries. When you consider that the most coupled endpoints just require a few joins/group by's/nested function queries, writing the rest of the queries takes only as long as it takes you to type a few sentences. You could easily have a Database type which offers a few methods (e.g. Do(), Query(), &Result) and export a map of these for each resource. Keeping track and reasoning about these is easy if you clean up and break up your monolithic app into packages.
  - voidlogic 12y ago
    >While this is a noble goal, when someone is building a new API or project, it's often impractical to commit to building an entire, full featured data layer in the process Thats why I mentioned this approach over an ORM for a high performance API / high value API. If you need something quick and dirty, do it the quick and dirty way after all. Although if you have written a lot of these, its not really so bad.
  - jbooth 12y ago
    Eh. It's a few lines of typing to add the additional interface, a line of SQL per function, and a few lines to write the annyoing unmarshalling code. Frequently, I find that by the time you figure out how to get an ORM to do what you want, you could've just written some datalayer code and have more certainty about what it's doing under the hood.
freyr 12y ago
SQLAlchemy is great, but SQL is also very expressive.
- aikah 12y ago
  The problem is never the queries but object hydration. That's the main reason devs are using ORMS, they model their domain then the ORM takes care of the impedance mismatch between the way data are physically stored and an OO system. SQL is fine,some ORM even implement their own SQL on top of their query builder. But hydration ? good luck doing that without an ORM.
hedgehog 12y ago
I like Go a lot but if you're used to SQLAlchemy there's really no equivalent. Gevent and PyPy will get you pretty far. On the Go side I have some experience with Gorp, it worked pretty well but for my application I needed performance more than the features I gave up.
abdullin 12y ago
We are rewriting a dating web site and the backend is implemented in Go. It exposes functionality as JSON over HTTP (along with some long-polling). We also considered erlang, Haskell, Scala and C# for various reasons. Coming from .NET world, I love the simplicity and power of database/sql in Go. Sometimes it can be too verbose because of error handling, but there is nothing that can't be fixed with a few helper functions. I've been documenting our project on a weekly basis, if you are interested in more details: http://abdullin.com/long/happypancake/ http://abdullin.com/long/happypancake/
tonyhb 12y ago
Yes, and the SQLx library is fantastic. It keeps the raw power of SQL while making writing it far less cumbersome. http://jmoiron.github.io/sqlx/ http://jmoiron.github.io/sqlx/

by bsaul 12y ago

voidlogic 12y ago

There are also ORMs such as sqlx or gorp. Personally, for a high performance API, I am a bit old school and I would rather for a given type Foo, I would rather write a FooDB struct that implements a FooDS interface. Everything in your app just uses FooDS. (DB = database, DS = datastore) Your FooDB implementation could be using any number of underlying technologies MongoDB, LevelDB, SQL, etc and it can change as your app changes and this change is transparent to the rest of your app (since the rest of your app uses FooDS).

hkarthik 12y ago
> Your FooDB implementation could be using any number of underlying technologies MongoDB, LevelDB, SQL, etc and it can change as your app changes and this change is transparent to the rest of your app (since the rest of your app uses FooDS). While this is a noble goal, when someone is building a new API or project, it's often impractical to commit to building an entire, full featured data layer in the process. Also in practice, database connectivity ends up being a fairly leaky abstraction, even if you write a database abstraction layer. Behaviors around CAP tradeoffs will bleed into your higher layers and require refactoring if you switch from one DB to another (unless you're going from one RDBMS to another).
- MoOmer 12y ago
  For REST APIs, writing the database queries are easy enough; and, often less painful than trying to figure out an API. I don't know of any Rails app that hasn't required some amount of custom queries. When you consider that the most coupled endpoints just require a few joins/group by's/nested function queries, writing the rest of the queries takes only as long as it takes you to type a few sentences. You could easily have a Database type which offers a few methods (e.g. Do(), Query(), &Result) and export a map of these for each resource. Keeping track and reasoning about these is easy if you clean up and break up your monolithic app into packages.
- voidlogic 12y ago
  >While this is a noble goal, when someone is building a new API or project, it's often impractical to commit to building an entire, full featured data layer in the process Thats why I mentioned this approach over an ORM for a high performance API / high value API. If you need something quick and dirty, do it the quick and dirty way after all. Although if you have written a lot of these, its not really so bad.
- jbooth 12y ago
  Eh. It's a few lines of typing to add the additional interface, a line of SQL per function, and a few lines to write the annyoing unmarshalling code. Frequently, I find that by the time you figure out how to get an ORM to do what you want, you could've just written some datalayer code and have more certainty about what it's doing under the hood.

freyr 12y ago

SQLAlchemy is great, but SQL is also very expressive.

aikah 12y ago
The problem is never the queries but object hydration. That's the main reason devs are using ORMS, they model their domain then the ORM takes care of the impedance mismatch between the way data are physically stored and an OO system. SQL is fine,some ORM even implement their own SQL on top of their query builder. But hydration ? good luck doing that without an ORM.

hedgehog 12y ago

I like Go a lot but if you're used to SQLAlchemy there's really no equivalent. Gevent and PyPy will get you pretty far. On the Go side I have some experience with Gorp, it worked pretty well but for my application I needed performance more than the features I gave up.

abdullin 12y ago

We are rewriting a dating web site and the backend is implemented in Go. It exposes functionality as JSON over HTTP (along with some long-polling). We also considered erlang, Haskell, Scala and C# for various reasons. Coming from .NET world, I love the simplicity and power of database/sql in Go. Sometimes it can be too verbose because of error handling, but there is nothing that can't be fixed with a few helper functions. I've been documenting our project on a weekly basis, if you are interested in more details: http://abdullin.com/long/happypancake/ http://abdullin.com/long/happypancake/

tonyhb 12y ago

Yes, and the SQLx library is fantastic. It keeps the raw power of SQL while making writing it far less cumbersome. http://jmoiron.github.io/sqlx/ http://jmoiron.github.io/sqlx/