The v0-alpha API will be removed at the start of May. It is currently available at the URL:
https://lorcast.com/api/v0-alpha
Please update your code to use the API available at:
https://api.lorcast.com/v0
The API Documentation can be found here: https://lorcast.com/docs/api
One of the most requested features for Lorcast was the ability to search with a shorthand keyword instead of the full word. At the start, I felt it was important to make sure the operators were correct and their usage felt good.
However, once you start doing a few searches it quickly becomes annoying to need to type the full rarity: (for example), when a shorthand operator would be so much nicer.
Well, you finally can do so! Searches like the following are supported:
i:amber or i:steel
(c>7 or c:5) e:shift -iw
t:action e:damage (e:character e:location)
It was important to get most of the keywords created first so the shorthands
wouldn't have conflicting overlaps. For example, e is used for text because
t was taken for type.
The Syntax Page has been updated with examples.
I launched Lorcast to the world this week on Reddit. It was well received and the feedback I got was fantastic. Thank you everyone for searching!
I created The Changelog to document past and upcoming changes. This is where API changes will be communicated when a breaking change occurs. I'll also document new features, fixes, and other changes.
I got a lot of great feedback from the community from the launch. There are several changes I need to make to the foundation of Lorcast, which I'll be rolling out in the next few weeks.
Lorcast now has much better support for variants of cards. This will make adding the promo versions of cards much easier and reduces the noise in search. When a search result returns the same card it will deduplicate it and only show one of them.
Further, each card page now shows all the variants of that card, what set they are from, and their rarity. You can see it on a page like Kida, Protector of Atlantis. Let me know what you think!
On the technical side, I switched the number column of a card to be a text column from an int. I'm using Postgres' COLLATE functionality to do ordering on that column treating it as a numeric column. The API reflects this change.
Lorcast originally started out using Prisma as the ORM. While Prisma handles a lot of simple interactions well, one thing it didn't handle well was the dynamic query generation for the search query. Because a user can create an arbitrarily complicated query, that SQL query needs to be dynamically created as well. Prisma's support for these queries requires the parameters to be placed within its SQL template string, which posed challenges when concatenating many queries together. The most straightforward approach was to use parameterized queries and let Postgres handle the parameter substitution.
So, for the searching functionality, I used pg, the Node.js Postgres package.
This left me in the awkward position of having two different database connections. While I could connect them with a Prisma adapter, I was still facing limitations concerning what Prisma was good at.
I didn't realize it at first, but there is a lot of data massaging that needs to happen in a card search! For example, Into the Inkland introduced Dalmatian Puppy, which has 5 different variants as cards. These collector numbers are no longer integers (1, 2, 3, etc) but now strings (4a, 4b, 4c, etc). Switching the database column to text means it's no longer easy to order by collector number, which is still a requirement! To resolve this, more complex ordering logic needs to be used for the queries. Again, this isn't hard in SQL but becomes messy when passing through an ORM like Prisma.
For these reasons, Prisma was removed.
or at the start of a string would incorrectly count that as a or lex token.