If I can make a vague suggestion .... So my exp...
# contributions
d
If I can make a vague suggestion .... So my experience with a few weeks in development (building a prototype SaaS app for schools) is that typesense is fast, reliable and seems well put together. The JS client is simple and clean and I'm a big fan of key-based authentication for client-side apps like this. If I had feedback, it would be that the docs could us some work - specifically, more examples, explanations of limited functionality (eg nested keys) - and real-world use cases. In my case, I'm using it as a query back end for Firestore. But, I was sort of expecting to be able to simply push my docs into Typesense and be able to start querying them - as I could with Algolia ...., but I can't easily do that ... OR i can but only with workarounds that weren't mentioned in the docs - if they had, it would have saved me quite a lot of time. Specifically, I'm referring to things like not being able to query nested fields, not being able to query dates, and having to work around things like Firestore timestamps, dealing with reference-type fields, handling arrays in auto schema mode, etc. In fact, each of these issues can be solved - dates can be converted to timestamps and stored as numbers, nested docs can be flattened out, and arrays can be explicitly defined in a defined schema. But had the docs discussed more of this upfront, I would have been able to get further, faster and start to take advantage of the product - and hence ship my prototype - much quicker. In a few weeks I hope to finish and ship this prototype. But if there is interest i could perhaps begin to create a 'cookbook' that discusses some of these concerns. I think its esp useful for those using Typesense for Firestore - which I imagine will be a big part of your business and growth - because those using Firestore are used to such documentation from Google and the Firebase team. Again, thanks on creating a great product! You deserve every success! Thoughts?
๐Ÿ’ฏ 1
๐Ÿ‘ 1
j
@Darren Carter I really appreciate this feedback especially with specific examples and solutions... I've heard that the docs need work recently, but this is the first time I've heard exactly what is lacking. Thank you ๐Ÿ™ I like the idea of a cookbook / guide for specific use cases, in this case integrating Firebase and Typesense. I'd definitely be down for a PR for this!
In fact just today I was planning to write one for folks migrating from Algolia to Typesense... Was wondering what to call it though, and I now like the word cookbook! We can may be have a separate section in the docs called cookbooks and have Algolia migration and your Firebase one under it
d
So @Jason Bosco The 'cookbook' idea - I've seen two great examples - 1. CakePHP, and 2: VueJS
I think the idea is that it's not really technical docs, like you currently have, because it neither handles the API in great detail, nor is it a guide that walks you through essential requirements - install, configure, deploy, etc ... it's a document that describes either common use cases or common issues and suggests* one or more approaches to address them.
To me, that's a big part of onboarding that's probably lacking in Typesense. I know you have your Firestore plugin (or whatever they call their add ons) .. but it doesn't handle dates/refs, arrays and neither does your guide.
j
Got it, yeah, now that you point it out itโ€™s obvious
@Darren Carter Iโ€™ve put together our first cookbook for users migrating from Algolia: https://typesense.org/docs/guide/migrating-from-algolia.html Is this what you had in mind when you said cookbooks?
d
Wow. Yes. That's a real help with migration from Algolia, that'll do wonders to help devs get off the Algolia Crack. ๐Ÿ˜‰ You did a great job Jason! ... so I guess one for Firestore too ... some of the quirks include: Nested objects Handing ref-type fields FS Date/time stamps Handling arrays of objects eg
[{ id: 1, label: 'one' }, { id: 2, label: 'Two' } ... ]
and how to index such a beast while not only returning search key fields eg
label
but also being able to re-hydrate the objects later in the client ....
I wonder if its even worth creating a sample serializer/unserializer for FS on github? IE: in a cloud function, serialize your docs like this on their way to TS when your adapter receives search results from TS, rehydrate/unserialize them like this ... to return the structure and utility to your objects I'm working on such a thing, if I get a chance I'll post a gist.
j
Thanks Darren!
A serializer gist would be awesome
Oh and your outline for a Firebase cookbook sounds good