I've been using Meilisearch in production for quite some time now, and TBH it has been one of the easiest service to maintain (I mean, it's just a single statically linked binary) and with close to zero configuration.
Is it really "just a single statically linked binary"?
I'd love to use Meilisearch as you describe, but their so-called SDKs are just for clients, so you still need the Meilisearch server listening on localhost.
I would love to see something like SQLite based on Meilisearch (i.e. a fully self-contained search library like https://github.com/mchaput/whoosh). Do you know if such a thing exists?
I was referring to the server daemon, not the client libraries.
But ofc, it's a process not an embeddable library, so you can't just link it against your app like you would with SQLite or rocksdb.
Although it looks like it's build around their core library "milli" though (https://github.com/meilisearch/milli/), so probably something doable in the future?
I know a lot of people feel like it, but life isn't a game. Our jobs aren't competitions. For the vast majority of people, they literally just work them so they can eat and have warm place to stay.
This is producing real results with economic value, regardless of the level of _cheating_ going on. This will make a ton of marginal programmers more productive (lines of code per day, bulldozer code) as well as unlocking interactive no-code solutions.
First world programmers larping at their jobs just got handed notice.
> First world programmers larping at their jobs just got handed notice.
And creative people who aren't that good at coding just got a foot in the door. I have plenty of ideas but am not a great coder so struggled to implement them. And I don't care about coding as a craft, I want to just do stuff that requires code.
Using the chatbot as a tutoring guide/workhorse has been immensely helpful to me and will only get more so.
This is super interesting because I feel the exact same way about Stable Diffusion and similar AI image generation tools. I'm not an artist but I have ideas in my head that I want to get out. I also don't care about making art as a craft, I just want to do stuff like make cool pictures.
In the end, maybe it can make all of us be creative in the different fields we don't have skill in.
I migrated from typesense to Meilisearch on a project after I found it had much better search accuracy. I can't exactly explain why, but overall Meilisearch results feel more relevant by default.
There are actually benchmarks that allow measuring search relevancy objectively, e.g. BEIR[1]. Manticore Search team did an effort to make a PR to include it to the list. The results are here [2]. Unfortunately the BEIR team seems to be too busy to review a whole pile of PRs including about Vespa. Nevertheless it would be nice to have both Meilisearch and Typesense there too since it's interesting what performance those non-tf-idf based search engines would show compared to BM25-based and vector search engines.
I migrated in April 2021 (latest version of typesense & meilisearch at that time).
I don't have a public dataset has it was a fairly large ecommerce catalog with close to ~500k entries. And again, it was just my own perception which is hard to define. I just found that Typesense was a bit off compared to Meilisearch on search accuracy, and of course could totally be different today with a more recent release.
Got it, thank you for sharing that. Typesense was at v0.19.0 around that time. Two prominent issues we had in that version were how we handled matches across multiple fields and how we handled "keyword stuffing".
We're now at v0.24.rc, and we've iterated quite a lot on improving relevancy since then, as more users shared their datasets with us and gave us feedback over the last 1.5 years.
If you get a chance to try out Typesense again in the future, I'd love to hear how relevance feels with the latest version, out of the box for your dataset.
PaymentIntents and webhooks are required because of SCA (3d secure) and other type of payments flow (Apple pay, Google pay or just Stripe Checkout) where the user might be redirected to some external services leading to the capture being validated asynchronously.
I have used many other payment providers (in the UK) that deal with 3D Secure (and have done for decades), there's nothing about 3DS that requires things to be asynchronous.
I am currently involved in a project to add Stripe support to a product, and it's a lot more complicated to set up a simple payment than other APIs on the market.
From everything I'd heard about Stripe, I thought the API would be really simple, but it's not.
When I had to integrate the new intents APIs back when SCA launched it seemed pretty clear to me that they tried to come up with an API that covers many use cases (relatively) uniformly but therefore coming at the cost of a huge complexity boost over ther initial "charge a credit card" experience, which, combined with hugely lacking docs on some corner cases we encountered, seemed like a pretty poor decision to me based on what made them useful in the first place when they launched. As things stand I would look elsewhere now for integrating payments
I'm not an expert dealing with PSP, but situations where a payment is validated through a "return to merchant URL" is risky and could lead to payment being captured without the merchant being notified.
Stripe abstracts away all the complexity having to deal with dozens of payments methods behind this single PaymentIntent API, which let you query the status of a payment at anytime (and webhooks are just a way to listen for updates in realtime).
> I'm not an expert dealing with PSP, but situations where a payment is validated through a "return to merchant URL" is risky and could lead to payment being captured without the merchant being notified.
There are ways to deal with that - a very simple one is a "mop up" process, as suggested by the GOV.UK Pay Service:
But then how is this simpler or better than listening for webhooks (push)?
Also, PaymentIntent allows you to query its state (pull) as described in your link.
1) If it didn't break backwards compat why did it bump the major version?
2) Constantly pushing major versions in order to ignore backwards compatibility and pass that problem on to consumers might not break semver but you're still wasting my time by expecting me to clean up your mess if I choose to depend on your library. (Which I won't)
Or are you suggesting vite will backport security patches indefinitely?
Re 2.: unless they plan to simultaneously support multiple major versions, they kind of do. Maybe not right away, but once the main branch of development is based on the new major version, that's the highest priority moving forward. All older versions might get backported bug fixes, but that's it.
I'm not bad mouthing anyone. I wasn't even specifically targeting vite. I just simply don't care for the people in the industry that think they have ownership over my time. If they want me to use their shit, they need to make it worth while.
The speed at which you release breaking change is the speed in which I run in the opposite direction.
Look at all the arguments in this thread "you don't have to" "its optional" "its just a small change" "it hardly even needed fixing".
Do they not realise that me even having to look at this cost me time and money? Do they not realise that when you multiply that out to all your devs at their day jobs and then multiply it across the entire stack of software all pulling these stupid stunts that it adds up to a huge waste of time for everyone involved except the snowflake that thought their breaking change was worth it?
