<story><title>If All You Have Is a Database, Everything Looks Like a Nail</title><url>https://pathelland.substack.com/p/if-all-you-have-is-a-database-everything</url></story><parent_chain><item><author>Glyptodon</author><text>I think&lt;p&gt;&amp;gt; &amp;quot;Isolate applications.  Keep different applications away from other applications’ tables.&amp;quot;&lt;p&gt;is only good advice if the tables are application specific data and you don&amp;#x27;t do microservices in that stupid braindead way that makes it so that everything from the admin panel to data visualization are their own &amp;quot;applications&amp;quot; with their own databases and doing things that would be even the simplest of queries becomes a project in writing what are effectively bad performance joins via random http APIs. IE have a data model and understand where the most painless boundaries are, don&amp;#x27;t throw up dozens of DBs for the hell of it.</text></item></parent_chain><comment><author>JMTQp8lwXL</author><text>&amp;gt; doing things that would be even the simplest of queries becomes a project in writing what are effectively bad performance joins via random http APIs&lt;p&gt;In some ways, is GraphQL trying to slap a fresh coat of paint on what is otherwise is a bad problem under the hood? At my employer, we&amp;#x27;re trying to adopt it, but we&amp;#x27;ve never addressed the underlying performance issues of the microservices, and now the slowness is quite apparent with the GraphQL wrapper tier.&lt;p&gt;This isn&amp;#x27;t a diss to GraphQL. The queries are awesome to write. The developer experience of writing &amp;#x2F; being the client of a GraphQL server is extremely excellent. But I feel I might not be alone in a journey that is playing out to be a mediocre implementation because we are avoiding the core problem.</text></comment>
<story><title>If All You Have Is a Database, Everything Looks Like a Nail</title><url>https://pathelland.substack.com/p/if-all-you-have-is-a-database-everything</url></story><parent_chain><item><author>Glyptodon</author><text>I think&lt;p&gt;&amp;gt; &amp;quot;Isolate applications.  Keep different applications away from other applications’ tables.&amp;quot;&lt;p&gt;is only good advice if the tables are application specific data and you don&amp;#x27;t do microservices in that stupid braindead way that makes it so that everything from the admin panel to data visualization are their own &amp;quot;applications&amp;quot; with their own databases and doing things that would be even the simplest of queries becomes a project in writing what are effectively bad performance joins via random http APIs. IE have a data model and understand where the most painless boundaries are, don&amp;#x27;t throw up dozens of DBs for the hell of it.</text></item></parent_chain><comment><author>bpodgursky</author><text>&amp;gt; even the simplest of queries becomes a project in writing what are effectively bad performance joins via random http APIs&lt;p&gt;Don&amp;#x27;t forget the part where the queries are impossible to test, because you can&amp;#x27;t spin up real instances of all 15 APIs in a test environment, so all the HTTP calls are mocked and the responses are meaningless!</text></comment>