factory_bot VS postgrest

I made Factory-js inspired by factory-bot (https://github.com/thoughtbot/factory_bot), supports Prisma and Drizzle ORM and more. TypeScript is now widely used in both backend and frontend, but there is no de facto standard factory library. I'm developing a web application using Prisma, trpc, and nextjs, but I was struggling with how to write more beautiful and readable back-end tests. That's why I made factory-js.

factory_bot: A fixtures replacement

Not sure if you want the execution speed to be faster, or the development speed. If it's development, you can use FactoryBot in a script to generate data easily once you have your factories set up.

For instance, thoughtbot/factory_bot.

> if you're a bunch of tool makers and you all know your audience of tool users then there's no benefit at all to have someone offended by the word "tool" in your workforce.

It kinda reminds me of the factorygirl -> factorybot [0] story. It was a cute enough name for a technical tool that plays nice among bros, and down the line you end up renaming your package and deal with the drama.

On brand image, I get your point. I think the corporations doing it best tend to juggle with multiple brands and segment their market accordingly. Then yes, an homogeneous, single focus brand will be more valuable, as it also help to push people outside of the target to your other brands.

[0] https://github.com/thoughtbot/factory_bot/wiki

Not sure I follow why this question is related to an OS like Windows, but when it comes to RSpec testing with different users, I would use Factory Bot and define a User Factory and add Traits such as Admin & Non Admin and use them in specs with their pre-defined attributes to what they can access based on your User Model and call them within the specs.

The factory-bot gem is used in almost in all of our spec files and it make our set up much more easier than when we use fixtures. Here is the tradeoff, the easier the gem is to use, the more likely you’ll end up with some pain to control its usage. And when the times come to tackle slow tests, the best bet you can take is to start digging into you factories because it’s likely they are the primary reason why your test suite is slowing down

Efate is actually the second test fixture library I've written and there were several lessons I learned after using the first iteration for several years myself. The first version was influenced a great deal by factor_girl (called factory_bot now), with a heavy dependency on strings to define and create the fixtures. It also wasn't very modular. You couldn't just import a specific fixture, you had to bring in the whole library. And it wasn't very extensible, if you needed to define custom behavior for how a field should be created, it wasn't very pretty.

I work at thoughtbot, you might know us for our open source work like administrate, factory_bot or shoulda-matchers.

As we continue to level-up our skillsets as developers in Rails, the utility of POROs (Plain Old Ruby Objects) becomes more apparent and appealing. Sometimes, the business object(s) you create do not require persistent storage to a database and are, therefore, outside of the scope of an ORM (Object Relational Mapper) like ActiveRecord. But how do we maintain simplicity in our test suite and continue to leverage helpful testing libraries like FactoryBot without one? This instructional article explores how to implement factories for POROs including common pitfalls, building nested resources, and factory linting.

hey hn, supabase ceo her

we just announced GA, after ~4 years of beta. for those who don't know: supabase is a postgres hosting company. we also host other open source "backend" tools that make it easy to get started with postgres (tools like PostgREST for auto-generate APIs [0])

we owe a lot to the HN community. you launched us 4 years ago [1], when we were just a few developers. since then HN has been a staple in our journey, one of the best sources of product feedback [2]

the GA badge is mostly to signify organizational readiness. we're at a stage where we can take any profile of customer. we have a support team that works 24/7, and a success team that will help customers improve their postgres usage. we released our Index Advisor [3] yesterday, and we'll be releasing a few more products this week that helps customer with performance and security.

on a personal note: i read HN most days, and love going through the ShowHN's to see what devs are building. thanks for being an awesome community and my favorite place to lurk on the internet. i'll stick around to answer any questions

[0] PostgREST: https://postgrest.org

[1] Launch: https://news.ycombinator.com/item?id=23319901

[2] HN journey: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

[3] Index Advisor: https://news.ycombinator.com/item?id=40028111

If you use PostgreSQL and are proficient with using its row-level security feature, you can choose from several tools/services built above RLS, including Supabase, PostgREST, and PostGraphile. They all provide a way to expose database CRUD as a web API, assuming you've configured the RLS rules to properly secure the access.

wget 'https://github.com/PostgREST/postgrest/releases/download/v11.2.0/postgrest-v11.2.0-linux-static-x64.tar.xz'

SupaBase is entirely based upon PostgREST. In fact, PostgREST is arguably 49% of their value proposition according to their own website. The other 49% is PostgreSQL. PostgreSQL of course is a super mature database, and some would argue the best RDBMS on the planet, so let's ignore that part for a moment, and consider it a mature thing and move on to PostgREST.

You don't need this PHP snippet:

To get the same functionality without the extra step, simply use PostgREST [1]

[1] https://postgrest.org/

PostgREST is a standalone web server that turns your PostgreSQL database into a RESTful API using the database's structural constraints and permissions to define the API's endpoints and operations. In this tutorial, you will create a simple note-taking app by leveraging PostgREST to construct a RESTful API for the app and using htmx to deliver HTML content.

You might find some info in the docs of PostgREST [1] or in the previous discussions on HN about it [2].

For the versioning, I just have a git repo where I keep every role, schema, table, view, function, trigger, etc. definitions. Every time I change something in the database I first change it in the git repo too to have an history.

[1] https://postgrest.org

[2] https://hn.algolia.com/?q=postgrest

Don't know if you would call this a "program" but PostgREST is written is Haskell too.

https://github.com/PostgREST/postgrest