Earlier quoted context omitted.
What language was used before Java?
probably java, i doubt decision makers want a rewrite unless they want to bring in hungry young developers and accept some hiccoughs
You’d be wrong.
It was Ruby.
Microservices are a tax your startup probably can't afford
261–270 of 272 posts
Re: Microservices are a tax your startup probably can't afford
#262Earlier quoted context omitted.
This may explain some of the popularity resurgence of SQLite (including distributed SQLite) It makes Database Per Customer type apps really easy, and that is something alot of SaaS products could benefit from.
Yeah, I keep telling people at work that we need to figure out how to make it easier for teams to manage their own DBs. There are so many teams trying to shove their data into some other team's DB.
It sounds like you're currently struggling against provisioning new database instances (or clusters) when the delineation is actually at the database within that instance
Compare:
psql --host=team1.example -d team1
# versus
psql --host=the-db.example -d team1
psql --host=the-db.example -d my_db -U team1 "select * from team1.orders o inner join team2.products p ..."
Re: Microservices are a tax your startup probably can't afford
#263Earlier quoted context omitted.
Microservices minimize devops/security/admin work? What planet are you living on?
I assume he means building the product out of AWS legos like Lambdas. Stick it all under one account, manage it manually instead of trying to deal with Terraform and it isn't too bad. Heroku is still way easier, though.
> manage it manually instead of trying to deal with Terraform and it isn't too bad
I'm firmly in team "fuck Terraform" but I'm also in team "read only console access" because otherwise "how did this thing get this way" is insanity
Re: Microservices are a tax your startup probably can't afford
#264[dead]
Re: Microservices are a tax your startup probably can't afford
#265Earlier quoted context omitted.
I've also seen the top down version where senior leadership like a CIO/CTO wants to put a huge "modernization" project on their resume and they don't care if it is impossible to maintain or falls over after they move on.
"Cloud Migration"
"Digital transformation"
Re: Microservices are a tax your startup probably can't afford
#266Earlier quoted context omitted.
I don't remember one solitary lecture on CI/CD, microservices, or even just deployment in general, in Uni. The closest that our comp. sci. classes ever came to touching on anything but the code itself was making us use SVN.
The difference between a software dev degree and a comp. sci degree.
I've never heard of or seen a Software Development bachelors degree?
I've seen Information Systems programs, that are usually CE, after-hours tracks. Neither Harvard, Yale, nor MIT have a software dev one, just Comp. Sci. I'm calling BS (no pun intended) on "software dev degrees" as a thing distinct from CS in any widespread fashion.
https://www.harvard.edu/programs/
Re: Microservices are a tax your startup probably can't afford
#267Earlier quoted context omitted.
The type system almost never catches a bug that proper testing would miss. And if the code has such nasty untested edge cases that you don't even notice a wrong type going somewhere, it'd probably behave wrongly even with the right types. Indeed "any" breaks type checking all around it, but it can be contained more easily in a helper func with a simple return type. Most common case is your helper does a SQL query, an…
> The type system almost never catches a bug that proper testing would miss. This is true, but the difference is you don't have to write a compiler, it's already written for you. The testing, you have to write, and do so correctly. A lot of the woes of statically typed languages can be mitigated with tooling. Don't want to repetitively create types from an OpenAPI spec? Generate the code. Don't want to create types f…
You need tests either way. It's hard to write a test that checks behavior but misses a wrong-type. Simply running the problematic code will most likely throw an exception.
The type deduction is not so automatic in most languages, TS included. Rust has the most automatic one I've seen, and of course that kind of language needs static typing. But still, it's more explicit than needed for a typical web backend.
SQL type autogen is limited to full rows, so any query returning an aggregate or something isn't going to work with that. Even for full rows, it's eh. Usually I just see that encouraging people to do local computations that should be in SQL.
Re: Microservices are a tax your startup probably can't afford
#268Earlier quoted context omitted.
> The type system almost never catches a bug that proper testing would miss. This is true, but the difference is you don't have to write a compiler, it's already written for you. The testing, you have to write, and do so correctly. A lot of the woes of statically typed languages can be mitigated with tooling. Don't want to repetitively create types from an OpenAPI spec? Generate the code. Don't want to create types f…
You need tests either way. It's hard to write a test that checks behavior but misses a wrong-type. Simply running the problematic code will most likely throw an exception. The type deduction is not so automatic in most languages, TS included. Rust has the most automatic one I've seen, and of course that kind of language needs static typing. But still, it's more explicit than needed for a typical web backend. SQL type…
> You need tests either way.
The argument isn't that with static types you don't need tests but rather with static types you can focus on testing what actually matters which is the fuction itself along with it's integration into the program. Tests won't cover 100% of the surface area of a function taking `any` as that is by definition infinite with the constraint on the shape specified in the body of the function dependent on the path taken at runtime (it might never be hit). I urge you to take a look at languages other than TS for this as TS is in the strange place of bolting on a static type system to rather messy language as what may be issues with TS may not be for the rest of the space of languages with static type checking (e.g haskell effectively requires no type annotations at all in theory but in practice it's often better to use them and with extensions it's required).
To add to that, try looking at Go, Elm, Zig, C#, mercury, and Idris to see different type systems at play rather than assuming TS and Rust are all that's available in this design space.
> Simply running the problematic code will most likely throw an exception.
The issue here is "most likely" which during a large refactor (and due to a wide spread use of duck typing) can hide many faults within the application that go without being noticed until a user hits that path. Static types turn this into a compile-error thus it won't ever reach production. If you have 100% path coverage and test every possible type that can be passed and ensure truthy values don't change behaviour (e.g `if ("")`, `if ([])`, ...) when passed (need to test the space where all of them evaluate to `false` in addition to `true`) you're still short of the number of variations that can be passed to your function and thus may end up in a situation in future where the wrong behaviour causes failure at runtime post deployment. This is not to say you should use types only and not tests (still test even with static types) but rather that the domain of possible things passed is reduced to a testable set of values instead of always being the largest path-dependent set possible.
> It's hard to write a test that checks behavior but misses a wrong-type.
It's incredibly easy to write such tests as most don't test the negative space of such functions nor is it easy to know what the minimal shape of an object may be for your function as it depends on which logic it hits inside. If a truthy value is used or a branch is made on a field or method call of the object then anything unused in the consequent branch is not checked by your test. You'd effectively have to resort to fuzzing to find what the minimal shape is for each possible path to have an idea of what your function doesn't catch in tests to get even close to static type checking (which is still far off as in some cases the set is so large it will never finish / enumerate all possible shapes).
> SQL type autogen is limited to full rows, so any query returning an aggregate or something isn't going to work with that.
Ask _why_ tooling doesn't work with that and you may notice it's due to a lack of specification or just insufficient tooling. Take F# [1] as the example here which can do far more [2] and doesn't suffer from the mentioned problem. F# is a language with static type checking.
[1]: https://learn.microsoft.com/en-us/dotnet/fsharp/tutorials/ty...
Re: Microservices are a tax your startup probably can't afford
#269Earlier quoted context omitted.
> The type system almost never catches a bug that proper testing would miss. This is true, but the difference is you don't have to write a compiler, it's already written for you. The testing, you have to write, and do so correctly. A lot of the woes of statically typed languages can be mitigated with tooling. Don't want to repetitively create types from an OpenAPI spec? Generate the code. Don't want to create types f…
You need tests either way. It's hard to write a test that checks behavior but misses a wrong-type. Simply running the problematic code will most likely throw an exception. The type deduction is not so automatic in most languages, TS included. Rust has the most automatic one I've seen, and of course that kind of language needs static typing. But still, it's more explicit than needed for a typical web backend. SQL type…
In my experience of dealing with loosey goosey languages (JS, PHP, Perl), 80%+ of the errors you will receive are because of the type system.
In PHP, if you look at your logs you'll see almost all the errors are checking an array with an index that doesn't exist. This is because people are using arrays as objects and then using strings as members. If you just use an object, this type of error is impossible.
So, we have to write `??` everywhere because anything can always be null and then it can break stuff.
And then you have errors with passing empty string vs null vs empty array to functions and getting unpredictable behavior. So you need to constantly check everything.
If you actually open up a function in a dynamically typed language, take your pick, you'll see something like this:
``` if (arg === '' || arg === null || arg === undefined || arg === []) ... ```
If you don't include checks like that everywhere, your code will break. You just don't know it isn't broken yet.
And, btw, something like PHP `empty()` is not a silver bullet either. Because it considers like a dozen different values to be empty. Which comes with it's own set of problems.
Re: Microservices are a tax your startup probably can't afford
#270Earlier quoted context omitted.
Yeah, I keep telling people at work that we need to figure out how to make it easier for teams to manage their own DBs. There are so many teams trying to shove their data into some other team's DB.
It sounds like you're currently struggling against provisioning new database instances (or clusters) when the delineation is actually at the database within that instance Compare: psql --host=team1.example -d team1 # versus psql --host=the-db.example -d team1 Sometimes one can get away with schema level split, which can allow cross schema references in a read only setup, but carries coupling concerns psql --host=the-…
Thanks, but it's something else. When I say people shove their data into other teams' DBs, I really mean into other teams' schemas... and they don't even have direct SQL access to their data anymore, rather the teams set up some CRUD API which they have to painfully maintain.
We aren't using Postgres but a more specialized DBMS. Everyone basically does the first thing in your example, sharing one cluster. The real issue is it's a big corp with red tape around stuff, people don't want responsibilities like compliance, and people are rightfully scared of keeping things performant on a fancy DBMS. Our team isn't scared, we did it, but it wasn't easy either.