4 ms·

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

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.

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.