4 ms·

Your counter counter argument on not being as flexible as SQL is spot on. A DAL that sits in front of storage mechanisms is not a bad idea though. I've found m

Your counter counter argument on not being as flexible as SQL is spot on. A DAL that sits in front of storage mechanisms is not a bad idea though. I've found moderate success in doing the reverse and using communication channels from SQL => services either via NOTIFY or queues. ie. Dispatching an event that signals a non SQL service to do an action. eg saving a file to S3, then updating the database when the action is complete. This doesn't really work when retrieving data synchronously but in most cases if the data is stored elsewhere - then you probably want to access it via non db methods anyway (ie. for an S3 file, you'd use the url) WRT JSON, please for the love of god no. Someone made the same argument a month ago, my reply here: https://news.ycombinator.com/item?id=18870838 https://news.ycombinator.com/item?id=18870838

da_chicken 8y ago
> WRT JSON, please for the love of god no. I don't like it either, but for most scenarios that this sort of thing works for a RESTful API or microservice or equivalent (or whatever you want to call it these days since I think the expiration date on those terms has elapsed) and not all data can be meaningfully coded without a structure like JSON or XML. Or, rather, you can, but, you're reinventing the wheel just like you would with an API trying to be as flexible as SQL. You may run into various system limits on URL length, too. Events and queues are great, but not all requests work that way. If you're USPS and you're providing an address and ZIP code resolver, you've got different requirements than getting data from one system to cascade across a series of systems with a dozen different asynchronous widgets. You'd have a burden of using a format that your customers would prefer, too.
- zepolen 8y ago
  Having worked with three large JSON http microservice based projects in the past, I abhor the day they got popular. Relative productivity has definitely gone down due to the project overheads caused by them. Not saying microservices don't work, they are great for specific use cases, but 9/10 people just want to microservice everything just to say they use microservices. > If you're USPS and you're providing an address and ZIP code resolver Not sure I see your point with this example - isn't a resolver like this just a fixed database of entries?
  - da_chicken 8y ago
    > Not sure I see your point with this example - isn't a resolver like this just a fixed database of entries? Until you get to how well it handles misspellings and incomplete information. Addresses are also notoriously difficult to parse. There is some logic and ranking at work behind the scenes. The only times I've seen it consistently fail are when the city is incorrect, or it's a genuinely new address (new construction or address renumbering). In any event, is a read-only service somehow less of a service? I'd wager read-only services see a lot higher demand than anything.

da_chicken 8y ago

> WRT JSON, please for the love of god no. I don't like it either, but for most scenarios that this sort of thing works for a RESTful API or microservice or equivalent (or whatever you want to call it these days since I think the expiration date on those terms has elapsed) and not all data can be meaningfully coded without a structure like JSON or XML. Or, rather, you can, but, you're reinventing the wheel just like you would with an API trying to be as flexible as SQL. You may run into various system limits on URL length, too. Events and queues are great, but not all requests work that way. If you're USPS and you're providing an address and ZIP code resolver, you've got different requirements than getting data from one system to cascade across a series of systems with a dozen different asynchronous widgets. You'd have a burden of using a format that your customers would prefer, too.

zepolen 8y ago
Having worked with three large JSON http microservice based projects in the past, I abhor the day they got popular. Relative productivity has definitely gone down due to the project overheads caused by them. Not saying microservices don't work, they are great for specific use cases, but 9/10 people just want to microservice everything just to say they use microservices. > If you're USPS and you're providing an address and ZIP code resolver Not sure I see your point with this example - isn't a resolver like this just a fixed database of entries?
- da_chicken 8y ago
  > Not sure I see your point with this example - isn't a resolver like this just a fixed database of entries? Until you get to how well it handles misspellings and incomplete information. Addresses are also notoriously difficult to parse. There is some logic and ranking at work behind the scenes. The only times I've seen it consistently fail are when the city is incorrect, or it's a genuinely new address (new construction or address renumbering). In any event, is a read-only service somehow less of a service? I'd wager read-only services see a lot higher demand than anything.