You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Create a real world tutorial to help everybody understand Laravel Lighthouse step by step #1476
I am willing to provide most of the code to create a functional blog with auth using vue-apollo What problem does this feature proposal attempt to solve?
This solves the getting started and the tutorial section of the docs with a real-world example, That will make more people or companies adopt Laravel Lighthouse into their projects.
The docs and tutorials are not very detailed on how to solve certain important features that you will find in a real-world app. Which possible solutions should be considered?
Creating a real-world blog to show the value of Laravel Lighthouse
ghost changed the title [-]Create a rela world tutorial to help everybody understand Laravel Lighthouse step by step[/-][+]Create a real world tutorial to help everybody understand Laravel Lighthouse step by step[/+]on Jul 16, 2020
Same as for upload example - go ahead and create it in extra repo. You could actually use the repo you already created for upload, and extend it. We could somewhere link your project in docs.
There is one thing makes me warily - as lighthouse grow and probably change some APIs, or introduce some new stuff, that breaks old stuff, you have to update your example. Do you think you can keep your example up to date?
It can be more complete for sure. A comprehensive overview would help greatly, too. I put a great focus on implementing proper tests for it to ensure that the example code actually works.
It can be more complete for sure. A comprehensive overview would help greatly, too. I put a great focus on implementing proper tests for it to ensure that the example code actually works.
There are a lot of things not used/answered, such as whole app/GraphQL directory possibilities.
First thing that comes to my mind is, add an updatePost so only you, as a logged in user, can update the post.
@genesiscz open for PR's that add bits of functionality to the example project!
I'd love to contribute, trust me, but my comment was more from the observer & someone who request this from somebody who knows the correct way to do something. I am using types, Queries, Mutation classes, but I am not sure I use them correctly or what are the possibilities. For example, I am not sure how is the BatchLoader used (I know there's a resource for that, but we're talking about the example here)
I think you might be conflating concepts here. It is my understanding that the roles in a token are supposed to be relatively static and reflect what the user is authorized to do. Generating that once on Login seems sufficient?
Can a user profile have this effect in our app @spawnia ?
It does not necessarily have to be personalized, although parts of it might be. I think it would be cool to have a bunch of different data sources all on the same page.
Also, would it be a good idea to create an interface for users
Might be good if they share a bunch of fields, but differ in others.
Manually re-defining the schema types in the frontend is very tedious. Especially when you consider that each and every query chooses just a subset of fields, which requires extra types. GraphQL Codegen takes care of all of that. I guess it will not work with Quasar, but plain vue-apollo should be fine: https://graphql-code-generator.com/docs/plugins/typescript-vue-apollo
I found Next.js quite nice to work with, personally and know the TypeScript + React + Apollo combination to work quite well.
if you pick Vue for the project and need SSR - nuxt.js is the best choice IMO. It doesn't add to much to the codebase, like quasar (with all the styled components etc), only tools and helpers you need, to design your frontend better and faster.
I also use enums for everything what is enumerable. UserRole is such an enum
If you want to use React - next.js is your choice.
I never used React, so if we go react way, I will not be able to help you there at all. @spawnia has there more expertise
In my projects I use nuxt.js with TS, and it works pretty well. To be honest - TS support in vue 2 and therefore in nuxt.js is "OK"ish, there are possibilities to work with it. I found a way, and I could provide the boilerplate with apollo and graphql-codegen configured. As Vue 3 is rewritten in TS completely, it provide completely TS support. I guess nuxt.js with vue 3 will be then released within a month after Vue 3 release. As I use this stack in my projects, I could also help to migrate later to nuxt with Vue 3. Vue 3 is gonna to be released in august this year
So it is up to you, what you want to use. In the real world both vue.js and react are awesome frameworks to work with.
@wolfiton i am pretty busy working on Lighthouse core and some other open source projects, so I probably won't be able to put much time into building your example app anyways. Choose what you are most comfortable with.
One nice thing about GraphQL is that the schema provides a clear contract to build upon, so adding another frontend to consume should be easy.
@wolfiton same here. Busy at main work + working on some side projects. But as I said, I am able to help due giving you directions, where to look at, and giving you some (adopted) examples of code, help you a little.
Didn't see this in detail, kind of... I don't know how is it looking now, but I had to write some additional code, to get it working on server side too. Also I am using multiple apollo-links, and I can add callbacks to upload-progress, very useful if you upload large files. I'll drop my code to your repo till Monday ;)
Activity
[-]Create a rela world tutorial to help everybody understand Laravel Lighthouse step by step[/-][+]Create a real world tutorial to help everybody understand Laravel Lighthouse step by step[/+]lorado commentedon Jul 16, 2020
Same as for upload example - go ahead and create it in extra repo. You could actually use the repo you already created for upload, and extend it. We could somewhere link your project in docs.
There is one thing makes me warily - as lighthouse grow and probably change some APIs, or introduce some new stuff, that breaks old stuff, you have to update your example. Do you think you can keep your example up to date?
spawnia commentedon Jul 16, 2020
Have you looked at https://github.com/nuwave/lighthouse-example yet? It is a quite minimal example I created according to best practices I found.
It can be more complete for sure. A comprehensive overview would help greatly, too. I put a great focus on implementing proper tests for it to ensure that the example code actually works.
genesiscz commentedon Jul 16, 2020
There are a lot of things not used/answered, such as whole app/GraphQL directory possibilities.
First thing that comes to my mind is, add an updatePost so only you, as a logged in user, can update the post.
spawnia commentedon Jul 16, 2020
@genesiscz open for PR's that add bits of functionality to the example project!
genesiscz commentedon Jul 16, 2020
I'd love to contribute, trust me, but my comment was more from the observer & someone who request this from somebody who knows the correct way to do something. I am using types, Queries, Mutation classes, but I am not sure I use them correctly or what are the possibilities. For example, I am not sure how is the BatchLoader used (I know there's a resource for that, but we're talking about the example here)
spawnia commentedon Jul 16, 2020
nuwave/lighthouse-example#9
spawnia commentedon Jul 17, 2020
You can use plain old middleware to add HTTP headers.
spawnia commentedon Jul 17, 2020
I think you might be conflating concepts here. It is my understanding that the roles in a token are supposed to be relatively static and reflect what the user is authorized to do. Generating that once on Login seems sufficient?
9 remaining items
spawnia commentedon Jul 24, 2020
It does not necessarily have to be personalized, although parts of it might be. I think it would be cool to have a bunch of different data sources all on the same page.
Might be good if they share a bunch of fields, but differ in others.
I tend to use Enums every time a value is actually enumerable, which roles are likely to be. Consider defining them in PHP, since that allows reuse in both the schema and the model: https://lighthouse-php.com/master/the-basics/types.html#native-php-definition
spawnia commentedon Jul 24, 2020
Manually re-defining the schema types in the frontend is very tedious. Especially when you consider that each and every query chooses just a subset of fields, which requires extra types. GraphQL Codegen takes care of all of that. I guess it will not work with Quasar, but plain vue-apollo should be fine: https://graphql-code-generator.com/docs/plugins/typescript-vue-apollo
I found Next.js quite nice to work with, personally and know the TypeScript + React + Apollo combination to work quite well.
lorado commentedon Jul 24, 2020
Here are my opinions:
I never used React, so if we go react way, I will not be able to help you there at all. @spawnia has there more expertise
In my projects I use nuxt.js with TS, and it works pretty well. To be honest - TS support in vue 2 and therefore in nuxt.js is "OK"ish, there are possibilities to work with it. I found a way, and I could provide the boilerplate with apollo and graphql-codegen configured. As Vue 3 is rewritten in TS completely, it provide completely TS support. I guess nuxt.js with vue 3 will be then released within a month after Vue 3 release. As I use this stack in my projects, I could also help to migrate later to nuxt with Vue 3. Vue 3 is gonna to be released in august this year
So it is up to you, what you want to use. In the real world both vue.js and react are awesome frameworks to work with.
spawnia commentedon Jul 24, 2020
@wolfiton i am pretty busy working on Lighthouse core and some other open source projects, so I probably won't be able to put much time into building your example app anyways. Choose what you are most comfortable with.
One nice thing about GraphQL is that the schema provides a clear contract to build upon, so adding another frontend to consume should be easy.
lorado commentedon Jul 24, 2020
@wolfiton same here. Busy at main work + working on some side projects. But as I said, I am able to help due giving you directions, where to look at, and giving you some (adopted) examples of code, help you a little.
lorado commentedon Jul 25, 2020
Didn't see this in detail, kind of... I don't know how is it looking now, but I had to write some additional code, to get it working on server side too. Also I am using multiple apollo-links, and I can add callbacks to upload-progress, very useful if you upload large files. I'll drop my code to your repo till Monday ;)
spawnia commentedon Aug 5, 2020
Closing this issue, happy to see your result. You can add a PR to link to it in https://github.com/nuwave/lighthouse/blob/master/docs/resources/README.md