magic VS postgrest

And while we're at it, if you count commits as cognitive work, Magic had 8,007 at the time I closed its source code. Later it's been accumulating some roughly 570 additional commits. 99% of these commits are done by yours truly.

Magic Cloud is the name of our platform. Magic is what allows us to deliver our AI solutions - So writing about our technology's security basically implies writing about Magic Cloud's security.

In the island of Cyprus, I'm the by far most productive GitHub developer with some roughly 12,000 commits. If you check out my username which is "polterguy", you will only see me on 4th place or something - However, this is because GitHub resets commits back to zero if you change your email address, and I really don't give a sjit, so I've not bothered to fix it. If you want to know "my credentials", then look at my work.

Hence, by creating small reusable AI functions, such as we've got the ability to do at AINIRO, any human being can prompt engineer a rich and complex AI app together, allowing his or her users to use natural language to interact with the software.

We already have several clients that are using our AI chatbot for these purposes - However, probably the best use case is our own software system, which is highly complex, and therefor difficult to initially understand. We get a lot of questions about Magic Cloud, and even though I love answering these questions, a lot of questions can be automated by the AI.

I've got an AI chatbot company, and because of that, I have to somehow relate to Google code. Google code is everywhere, and creating a website without using Google code is almost impossible for these reasons. Google Analytics being one reason, and Google reCAPTCHA being another reason. If you've got a website, there's a 99% probability that your site is running some Google code.

As an additional bonus, it completely eliminates all Postman script kiddies, since the client must be able to execute code to create a valid token. It also eliminates reusing the same token for multiple servers, since each server has their own unique public key - In addition to that you get to market your AI chatbot as "powered by Blockchain technology", and you can actually say that out loud with a straight face, without lying ... 🤪

As an AI chatbot provider, we need some serious bot protection to prevent malicious users from creating bots that attacks us. Google reCAPTCHA of course is "the industry standard" here, which I'm sure most readers are aware of.

I just swapped out Google Analytics with Plausible for AINIRO.IO. It’s only been a week, but so far I am super jazzed about it. First of all, Plausible doesn’t use cookies, so I can completely drop all cookie disclaimers and popups I had because of GDPR. Second of all, the site scores significantly better on load time. This results in a 10x better user experience for my website visitors, while making sure the website is still 100% conforming to GDPR laws.

After having owned an AI chatbot company for more than a year, I finally did what I'm supposed to do before I even start a company; I did a Competitor analysis - And o'boy should I have done it earlier.

I think I know what you're talking about because I ran into this too. In defense of Supabase, you can still use transactions in other ways. Transactions through the client are messy and not easily supported by PostgREST.

The GitHub issue here sums up the conversation about this:

https://github.com/PostgREST/postgrest/issues/286

So... your comment is a bit disingenuous. Regardless of Hacker News's thoughts on MCP servers, there is a cohort of users that are finding them to be immensely useful. Myself included.

This is especially helpful because Supabase uses PostegREST under the hood, which does not support OpenAPI 3.x. Note that some Postgres specific features like enums are not converted to JSON Schema enums as Sequelize doesn't expose that information.

PostgREST stands out as the leading solution for PostgreSQL databases. It turns your database directly into a RESTful API with minimal configuration. The tool automatically creates endpoints for tables and views, supports complex filters, and leverages PostgreSQL's row-level security for fine-grained access control. If you'd like to see this in action, check out our Neon PostgresQL sample.

PostgREST

> I don't really see how the validation schema and ORM model would ever really diverge...

If that were the case, then using a PostgreSQL API[0] that maps tables to APIs would be all that's required.

However, the real world is messy. Requirements change, which could lead the project becoming a reimplementation of full framework such as Django.

Django also comes with generic REST endpoints based on models thus giving you the magic, but still allows for all the different use cases and customizations that might present themselves during the full lifecycle of a project.

[0]https://github.com/PostgREST/postgrest

PostgREST 12.2 is out! It comes with Observability and API improvements. In this post, we'll see what's new.

Supabase provides a RESTful API using PostgREST. However, without RLS, you will expose your database to the frontend. With the RLS policies created above, it’s safe to expose the API to the public because each user can only access the data allowed by the policy. For example, if you try to get all the List items using the API below, you will only receive the ones you are allowed to read by the read policy:

I spoke at Swiss PgDay in Switzerland in late June. The talk was about how to create a no-code API with the famous PostgreSQL database, the related PostgREST, and Apache APISIX, of course. I already wrote about the idea in a previous post. However, I wanted to improve it, if only slightly.

Supabase was started as a thin deployment layer on top of PostgreSQL and PostgREST, which implies that understanding Supabase requires understanding PostgREST and PostgreSQL.