i just wanted to update to prisma 1.2 and now i ge...
# prisma-whats-new
s
i just wanted to update to prisma 1.2 and now i get an error on building the typescript “node_modules/graphql-yoga/dist/src/types.d.ts(7,37): error TS2307: Cannot find module ‘graphql-subscriptions/dist/subscriptions-manager’.”
a
Hi Simon, that is strange. Could you please try a
npm i
within your application directory and try building the app again afterwards?
Or if you are using
yarn
->
yarn
🙂
s
i did install everything and yarn also did nothing different 😕
i get however some warning on npm install, but i think those where the same that i used to get the version prior
npm WARN apollo-cache-control@0.0.9 requires a peer of graphql@^0.10.0 || ^0.11.0 || ^0.12.0 but none is installed. You must install peer dependencies yourself. npm WARN apollo-server-core@1.3.2 requires a peer of graphql@^0.9.0 || ^0.10.0 || ^0.11.0 || ^0.12.0 but none is installed. You must install peer dependencies yourself. npm WARN apollo-tracing@0.1.3 requires a peer of graphql@^0.10.0 || ^0.11.0 || ^0.12.0 but none is installed. You must install peer dependencies yourself. npm WARN apollo-upload-server@4.0.2 requires a peer of graphql@0.11 - 0.12 but none is installed. You must install peer dependencies yourself. npm WARN graphql-extensions@0.0.7 requires a peer of graphql@^0.10.0 || ^0.11.0 || ^0.12.0 but none is installed. You must install peer dependencies yourself. npm WARN graphql-playground-middleware-lambda@1.4.2 requires a peer of aws-lambda@^0.1.2 but none is installed. You must install peer dependencies yourself. npm WARN apollo-link@1.0.7 requires a peer of graphql@^0.11.3 || ^0.12.3 but none is installed. You must install peer dependencies yourself. npm WARN graphql-tools@2.20.2 requires a peer of graphql@^0.11.0 || ^0.12.0 but none is installed. You must install peer dependencies yourself. npm WARN subscriptions-transport-ws@0.9.5 requires a peer of graphql@^0.10.0 || ^0.11.0 || ^0.12.0 but none is installed. You must install peer dependencies yourself. npm WARN rnv-graphql-backend@ No repository field. npm WARN rnv-graphql-backend@ No license field.
and it also works, if i run, so there must be something else 😕
a
I can reproduce the problem now as well. This is the corresponding issue: https://github.com/graphcool/graphql-yoga/issues/173
s
ah nice, thanks 😃
good to know its not my noobish typescript/node abilities
a
hehe ... no worries 🙂
To keep you in the loop. I found the problem 🙂 https://github.com/graphcool/graphql-yoga/issues/173#issuecomment-366034506
apollo
just published a version in which the requested type definition is not available.
s
jeah, allready seen it 😉
thanks
a
👍
s
by any chance, do you have a working example of a serverside subsription? I dont get the docu here https://www.prismagraphql.com/docs/reference/server_side-subscriptions/overview-to1ahf0ob6
a
Ehm, not an example I could show, sorry. 😞 Which problem are you facing?
s
The docu says, that i have to define the subscription in the yaml file, but not where or how i link a js file to it to do something. I have just never seen an example for these subscriptions 😕
i just dont get how to do even start with it…
ah, i found an better example and managed to get it to work in my application 😃
a
Awesome 💪 Do you have the time to propose a PR for the docs with your example?
s
jeah, i wouldactually do that, but i am still missing the last bit as i do not know how to subscribe on my own events
i can subscribe with a client, but dont get how i can listen to the event as the server
i have this on my resolvers
, Subscription: { movesMade: { subscribe: async (parent, args, ctx, info) => { return ctx.db.subscription.gameSession({}, info); }, }, },
and would like to make something like a concurrent thread, that listens on this event and then does something
and i am not even sure, if this is the right place to do that…
a
So the example described in the docs works as follows: You define the subscription within the
prisma.yml
. Your Prisma service will then send a HTTP request to the endpoint you have defined in there.
It behaves like a Webhook.
s
i got that, but i want to use it on my server, not as a webhook
a
What do you mean with "on my own server"?
s
i want to change stuff on the db, when something is created
like saving an invoice if a user finishes a checkout
something async, that does have nothing to do with the acutal mutation, to keep things separated
i am used to event driven design and want to check if this works well with prisma
a
Sure, that is the main aspect of that kind of subscription. The endpoint would be an own HTTP application that takes the request and could then also send a mutation back to your Prisma application.
s
cant i listen on my own events?
a
Absolutely. That is all this is about 🙂 Emitting events when something changed.
But to keep things separated why would you write it back to the same database?
s
i would need some sort of client running on my server code, that subscribes on the subscription endpoint, and i thought the serverside subscription would mean doing exactly that
well that is a good point, a separate db and service would certainly be a good idea
for example, i am having a simple game where you can move players and when you get on the same field, the good guys win
a
You can spin up an ordinary WebSocket client within your Prisma application in order to listen to your events, but IMHO then you could also write the invoice object straight in your mutation resolver as well.
s
but when i move a player, i do not want to set the game to the state finished in the same transaction, as i think that should be done by some other business logic
maybe i want to change the condition the game is won or a player moves
then i would have to change the same code
which violates the single responsibility principle in my opinion
i do not have a better example, but I know i faced a lot of similar issues in the past where i kept things separated this way
a
Sure, but in an event-driven architecture you are also performing the logic that reacts to the specific event in a different part of the system, which then emits another event -> leads to a state change in a materialized view.
s
yes, but for doing that, would i not need to listen to my own events?
*also
like the mail sending example
a
Yes and you can do that by using the example from the docs, write a HTTP endpoint that takes the passed event and performs your business logic OR use a WebSocket client and subscribe to your subscription endpoint for consuming your events that way.
s
if i want to send a mail when a user gets created, from my own server (let aside that the business server should not do that) i would need to listen to my own events
yes, the websocket idea seems like the way to go for me
i was just assuming that i could use prisma as some kind of event store out of the box
just by the way, do you contribute to the graphcool projects?
a
Exactly, Prisma can be used as an event store out of the box 🙂
Let me see if I can find a good example for you.
s
that would be awesome 😃
a
Soo ... I'm getting back to you now.
Personally, I would split your logic into an own application, but what you could do within your application directly is:
const sub = await context.db.subscription.user({where: {updatedFields_contains: ""}})
This gives you an
AsyncIterator
.
You can call
next
to get the next event out of the subscription.
s
sorry for being such a javascript noob, but this call is the exact same thing i do in the resolver. I thought i kind of have to register there to get the updates, as soon as the events are invoked. I also do not have acces to the db object outside of the resolver const in my sample project