haha @thisismissem that story is so spot on what i want to avoid! i really do not want UUID in my slugs, but making a generic solution will kind of need that. So i would need to make something like mixing in the username + project + postTitle to not get that, and it’s just a big headache atm, so ill continue to build my app, and take it for a rainy day where i don’t know what to do (like it ever happens though ) hehe

We had the same conversation in a company i to work for as well, it wasn’t easy at all, but they are all about SEO so it was one of the first challenges to be tackled

yeah, generating slugs is a pretty complicated topic

Friendly_id from the rails community does a really great job at it

I'd imagine if there was a way to mark a field as a

Slug

type in the graph.cool editor, then it'd be a custom type which asks you from which fields you'd like to generate the slug and what characters to use for separation and such

@thisismissem that’s a pretty cool way to implement in the graph.cool editor!

I could probably do up a UI mock, but I imagine it'd be much like doing the Enum types

/cc @schickling

@emilrmoeller something like this will be possible soon based on Lambda functions! For now using mutation callbacks should also be a feasible option.

@schickling that sounds awesome! I’ve never worked with Lambda but i’m looking forward to use it! I made it work with mutation callbacks for now, but there’s still some features i can’t make work with that approach, it’s “candy” feature, so ill wait with them! Can i see the plans for Lambda functions somewhere ?

Webtask is also a simpler great alternative to Lambda. We'll soon announce more plans around Functions!

I can’t wait! I’m looking very much forward. My app is progressing so fast using graph.cool it rocks!

@schickling that seems like a particularly expensive way to do this, but I guess I can understand why you'd want to take this route

I'm guessing it'll be a "callback pre-write"

seems like a tonne of network / i/o junk though to scale

Yes @thisismissem but that's where Lambda shines and we can a lot of smart caching.

yeah?

I've not worked with lambda heavily, but doing a network call around the whole thing means extra time

e.g., race-condition waiting to happen

as you'd have to lock on all rows (at least for that field) for the time it takes to do a network round-trip to lambda

otherwise the ID that lambda comes up with may not be database unique

as you could have two requests processed simultaneously

It's in fact pretty difficult too implement

In general we design our systems to not require locks for this exact reason. Optimistic Concurrency is a better model when operating at scale and would apply directly to this case

anything that combines uniqueness and non-database generate values is in practice pretty hard

@sorenbs so if by the time my lambda returns, something already exists with that value (assuming the field is unique), would my lambda proc be called again with a slight jitter in the time scale?

(Oh, important thing if you decide to implement subscriptions and realtime — always include reconnection time jitter. Otherwise you'll DDOS yourself. (this happened at pusher.com)

We are still defining exactly how this works, but that’s the general idea.

Alrighty