exevp

Nocode AI-API platform: https://flowtastic.ai

Started it some months ago because i needed it and it didn’t exist back then. Now there are some similar competitors but it still has some unique properties.

Traction: regular signups, paying customer, some recurring users.

Needs some UX love and features/polishing to be self-servicable.

Psssst, if you put it this way it won't attract VC $$$

So cloning yourself is the actual idea you should pursue? ;)

This space is getting so much interest that OpenAI will not be the only one providing LLM as a service forever.

You can use clean and smudge filters in git. Since notebook files are JSON it's pretty straightforward to stripe outputs from them using `jq`:

http://timstaley.co.uk/posts/making-git-and-jupyter-notebook...

This is probably a good opportunity to have a heated discussion over parseInt() vs Number() since parseInt('Infinity') yields NaN. I know people prefer Number() for reasons but in this case it reveals the weakness of using basically a typecast with implicit language semantics for interpreting string inputs.

Also the example of bypassing this is rather contrived:

1) bypassing some timer in an API service requires the API to accept the string „Infinity“ and convert it to the JavaScript value Infinity - which is highly unlikely. Instead, the value would just fail the numeric validation.

2) bypassing some timer in client-side code by injecting Infinity seems overly complex - if you alter client-side code you might aswell just remove the validation instead of abusing edge cases of the language runtime.

The last Bitcoin will be mined in ca 120 years. [1] Maybe better invest in longevity research if you wish to witness this event.

[1] https://bitcoin.stackexchange.com/questions/10486/when-will-...

> I am not sure about what do you mean here?

Given i have defined the columns of interest in my data objects anyways...

  class User { name = null; email = null; }

... i wouldn't necessarily have to repeat them when writing my SQL:

   sql`SELECT ${Object.getOwnPropertyNames(new User).map(camelCase).join(', ')} FROM users`

Of course using a better helper function.

There's a few repetitive tasks when writing SQL where don't necessarily need a powerful query builder but still end up writing a few handler functions. Shipping some common helpers with the framework might be handy.

I understand where Prisma is coming from with the custom DSL: they want to guarantee type safety and therefore need to know exactly the structure of the types the result set is supposed to be mapped to.

In most other languages you'd shout "reflection" but unfortunately, there is no such thing in TS. Hence the custom DSL so you know, while parsing, what the structure of the type is.

I'm just asking myself: why invent the custom DSL for that? You could just use babel to parse TS types. Sure babel is quite the dependency but in a node environment, that wouldn't be a bigger concern to me then inventing a custom DSL instead.

You could even use TS decorators to add more metadata like sequences and (foreign) keys to the TS types.

> In my experience this is just a very, very small percent of the cases. Most of the time I find myself doing pretty simple CRUD operations, and the boilerplate for the simple cases goes out of hand quickly, specially when running joins.

That's true, although the most frustrating percent of the cases :)

I think what KISS will eventually need is some simple toolbelt for the basic CRUD queries, e.g. expanding lists of column names, dealing with casing (snake_case to camelCase). So making the stuff you write 90% of the times easy without inventing a custom SQL abstraction.

MyBatis (which i mentioned in another comment) approached this for example with sql snippets one could re-use in queries.

KISS enables the same thing by allowing nesting of tagged sql strings. I guess time will show which additional helpers are needed to make the devs life easy/reduce the boilerplate for the simple queries.

Also one of the bigger reasons why i dislike SQL abstractions: you usually pick your RDBMS for a reason, because of some vendor-specific features, extensions or something. Abstracting SQL away makes end up with the smallest common denominator which defeats the purpose of choosing one specific RDMBS.

So whenever you have reasons to spend some thoughs on the choice of RDBMS, you'll probably not want to abstract SQL away.

Not specific to TS, just one of the modern JS features: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Scroll down to the part explaining how to use custom tags.

> not care about managing DB connections, at least until they become critical for my use-case.

That's something the db driver usually does. E.g. when using Postgres, the pg library already comes with the connection pooling. Haven't looked into the implementation in Knex but i'd suspect they just use the Pool class of pg (https://node-postgres.com/features/pooling).

> Not care about sanitising inputs and protecting myself from SQL injections.

That's also not that much of a concern when just binding parameters.

> Have more readable and maintainable code in my repositories than SQL in plain strings as a default. Yes I have some raw queries but 98% of my queries are easy to follow knex chains.

Comes with the cognitive cost of maintaining another abstraction for SQL.

> Not care about creating and maintaining code for migrations.

That's actually the one feature which made me use Knex for years (just for the migration part of course :) ). I didn't use the schema builder functions mostly, just a bunch of `knex.raw` calls in the migration files. But for the benefits you mentioned (transactions, bookkeeping) it is really useful.

I find that most of the production features you mentioned are actually more difficult using a fat ORM.

How many hours have i wasted figuring out how i can write and map some complex joins or aggregation query with <insert ORM name here>? Would have been a 3 minute task if all i had to write was just SQL ...

Plus i have a hard time seeing the benefit of Prisma. You are learning an entirely new DSL just to define your schema - which actually isn't that far off standard JS or TS syntax-wise so it feels like a complete waste of time to come up with the DSL in the first place. I can only imagine the hard time you have once you first have to break out of the frameworks cage because you hit a case which isn't easily solved by the framework itself ...

It might be a good idea to focus on the use of template strings for safe and handy SQL generation instead of introducing too many opinionated ORM concepts.

If one had to, i'd separate these things in different libraries and let the developer opt in to what he needs.

tl;dr: thank god it finally has been done.

Long version: i've been seriously frustrated with the state of ORM (in Javascript in particular) for years.

Javascript ORM are nice and handy if all you're doing is simple CRUD stuff. If you're starting with more complex relational queries (we're using an RDBMS so why wouldn't we?) you quickly reach the limits of what the ORM can map. If you start doing more complex aggregations or stuff like window functions and the likes, you most certainly have to fallback to raw queries, usually rendering the whole mapping function of the ORM completely useless.

Also projects like Knex.js (or for example HQL in the Java world) look nice at first but are mostly useless IMHO because they just replace SQL with another syntax you have to learn. Why stay with the language everybody familiar with RDBMS can speak if you can invent some useless abstraction, right? And please don't tell me you want to support multiple RDBMS in the same codebase. How often is this really an important use-case?

I really loved the way MyBatis did this in Java: instead of mapping tables to objects, mapping result sets to objects and leaving the full power of SQL to the developer.

Always wanted (and actually started something almost the same as you did some weeks ago) to basically do MyBatis in Javascript and never had the time to.

Thanks for getting it started.