Roadmap

[lvarayut]

Update: We stop supporting Yeoman for now, until we can find a good way to maintain it in our project, see more details #72.

Here is all the features planned to be developed. I list them out in order to make it easy for everybody to discuss and participate in the project. These features could be changed as needed, so don't hesitate to express your ideas. If you wanted to help developing some features, which would be very appreciated, please leave a comment below.

• Example on Heroku @lvarayut
• Official website (gh-pages) @lvarayut
• Yeoman generator @lvarayut
• Integrate css-modules @lexun
• Mutation example @Zenyai
• Flow* @Neitsch
• Data loader* @Neitsch
• Database integration* (MongoDB, MySQL, Postgres, and Cassandra)
• Yeoman sub-generators (Component, Container, Query, Mutation)*
• Testing framework (which one do you prefer: Jest, Mocha, Jasmine, Ava?) @lvarayut
• Server Side Rendering
• JSON Web Tokens* (Implement* Signup and Login pages) - This will be developed after Database integration
• Browsersync

*must be developed in canary branch.

[keon]

This is awesome, thanks for the project!
But why Browserify when you already got webpack?

[keon]

Also when adding database integration, adding all the graphql schema and mongodb (mongoose, likely) schema into one folder seems to be counter intuitive. Why don't we split GraphQL schema into /graphql and database into database or conventionally called model?

So the proposed files structure might look like the one below:

   ├── models                   
   │   ├── index.js 
   │   ├── User.js
   │   └── Feature.js 
   ├── graphql 
   │   ├── schema.graphql
   │   ├── schema.js
   │   └── schema.json 

[lvarayut]

why Browserify when you already got webpack

Thanks for expressing your idea. Browserify was a typo. It meant to be Browsersync instead.

Why don't we split GraphQL schema into /graphql and database into database

Yes, when integrating the MongoDB, I have planned to restructure the schema/query/mutation structures.

[keon]

@lvarayut I can work on MongoDB and Mongoose part
Please refer to my fork to see my proof of concept.
(It might be immature as I am building it while learning graphql)

[lvarayut]

Thanks @KeonKim. That would be great. Don't worry, take your time to learn GraphQL and complete your MongoDB in your fork. I can check it out afterward. However, you might also consider that do we really need to use Mongoose or just the simple MongDB driver is enough. Also, JWT is the preferable choice for authentication.

[AhmadEl-Banna]

@lvarayut @KeonKim if you decide to go with MongoDb and mongoose ,have a look at https://github.com/RisingStack/graffiti-mongoose,
I think it will remove a lot of redundant work with graphQL

[lvarayut]

@AhmadEl-Banna, Thanks for your suggestion. @KeonKim has suggested it also. I'll take a look at it.

[sachgits]

Hi everyone love the progress been using these and after checking the Roadmap issue i wondered why not contribute to these. and by look of who is working on what seems like the JWT is open as it waits for the mongoDB (mongoose) database. i don't know much yet on JWT but i do research on it and take part on the login and signup pages that's if am welcome hahaha thanks guys

[lvarayut]

@sachgits, I would say that the JWT should be done after the database integration. If you could, please take a look at the database integration before digging down into JWT.

[sachgits]

@lvarayut ok let me do that also to add i think that they types should have separation inside of schema and with of which Persons Types, Feature Types node definitions and connection definitions should go separately

[lexun]

I've been enjoying Mocha for testing, and it seems to be the default choice in the React community these days (Just look through some repos here: https://github.com/reactjs).

As for database, I'd love to see the core of this boilerplate stay flexible if possible. I've been experimenting with some RethinkDB configurations and think there is a lot of potential there.

[lvarayut]

Thanks for your suggestion. Mocha looks really good to me. The project is currently split into two main branches; master and canary. The master branch always stays flexible as much as possible by containing only general technologies needed by all the projects. On the other hand, the canary branch is integrated with Yeoman, called generator-relay-fullstack, which allows you to choose technologies that suit your needs; Database, Flow, and etc. The generator presently works with minimal functionalities, a lot of things are coming up \ (•◡•) /

[lexun]

Any thoughts about using css modules? I'd be happy to cut a branch to show what it could look like.

https://github.com/css-modules/css-modules
http://glenmaddern.com/articles/css-modules

[lvarayut]

That would be awesome!

[lexun]

See #18

[nodkrot]

How about https://github.com/Khan/aphrodite ?

[lvarayut]

@nodkrot It seems to be the same concept as css-modules except it's including everything in the same JavaScript file. BTW, @lexun has integrated css-modules which allows you to have a separate CSS file, and then, you can import it in your JavaScript which is more convenient, in my opinion. Most of the cases, you will have some business logic in your JavaScript file and you might not want to mix both styles and the logic together.

[mjurincic]

Database integration with classical RDBMS-es like MySQL/PostgreSQL would be also great, enterprise Apps still depend on them although NoSQL DB like MongoDB plays nice with mentioned graffiti-mongoose integration, there are projects already projects tackling those problems https://github.com/mickhansen/graphql-sequelize, maybe making it an option in Yeoman when scaffolding projects.

[lvarayut]

@mjurincic, that's a good idea. The database is totally optional and will be an option in Yeoman, generator-relay-fullstack.

[sachgits]

hey worked on testing barebones serverside might not be perfect yet but please take look at it and let me know what you guys think before i start on client side testing
#19

[jonstokes]

Just wanted to drop in a note and say how much I love this project. I'm coming to react/relay/graphql from the rails world, and I've been looking for an opinionated generator that uses the same basic add-ons and tools I'm already using in my react projects (i.e. webpack, css modules, babel, etc.). So this is just perfect! Just looking at the generated default site has answered a bunch of questions I had about good ways to organize my code..

[lvarayut]

@jonstokes, Thanks for your kindly words! I'm very glad to hear that the project is useful to you. I will keep improving it and make it even easier to get started with Relay and GraphQL 🚀

[imzautomation]

Hello i am using relay full stack but I am facing some issues I have a django backend serving graphql endpoint at 8000 port I used graphene to build the graphql server by follwing the tutorial provided in Thierry website , I have a schema.json file generated and it resides in backend folder how do integrate this with this kit ? What changes do I have to make

[lvarayut]

@imzautomation Thanks for your question. Could you open a new issue and show your full error log?

[imzautomation]

@Ivarayut sure will do thanks

[Rohit-cheddr]

Any tips on how we can go about integration tests? It seems like the relay wrapper could cause issues if we do a full dom render.

[lvarayut]

@Rohit-cheddr, Unfortunately, we haven't explored the testing yet. Will let you know as soon as we can.

[Extra-lightwill]

@lvarayut Add Cassandra to database integration?

[maksugr]

Do you think add react-mdl as default dependency is a good idea? It's seem like personal preferences.

[maksugr]

Have you thought about implementation additional flux implementation (Redux?) for local state? With Relay it's difficult to work with local state that coming not from Relay (client side authorization and so on).

[lvarayut]

@Extra-lightwill, Thanks for your suggestion. We could absolutely add it.

---

@maksugr:

Do you think add react-mdl as default dependency is a good idea? It's seem like personal preferences.

You're absolutely right, we should replace it with vanilla CSS to be totally agnostic. PR would be really welcomed

Have you thought about implementation additional flux implementation (Redux?)

In Relay2, which would be released very soon, will support a local state. We would prefer supporting Relay2 instead of implementing Redux.

[robrobkay51]

@lvarayut How far along is the database integration currently/ is there a rough timeframe on it?

[lvarayut]

Hi @robrobkay51, sorry, I don't have any timeframe, for now, I will let you know if there is any update.

[robrobkay51]

@lvarayut I don't know if anyone's made any progress already but what about https://github.com/mickhansen/graphql-sequelize for MySQL and PostgreSQL and https://github.com/masumsoft/express-cassandra for Cassandra. MongoDB im not sure.

And for JWT auth one of the below:

https://github.com/auth0/express-jwt
https://github.com/hokaccha/node-jwt-simple

Also worth noting re: server-side rendering, Relay 2's approach:

'Our overall approach with the new core has been to build simple primitives that can be built upon in user space. So for example, there is a clear separation of the React integration layer and the core - the former being implemented entirely via the public API of the latter. It might take a few releases to refine and document this, but i expect that it will be easy for the community to build upon this to make a server rendering module for Relay.'

[Extra-lightwill]

@Neitsch and myself are currently working on a mini-project to demonstrate SQL database integration. If anyone wants to contribute, please feel free to add to this repo: https://github.com/Extra-lightwill/gql-sequelize-ver01.

Currently, database models, mapping and schema are setup (AFAIK, correctly). Hopefully, with this, we can demonstrate how to provide full integration with SQL databases for Relay Fullstack. Here is the roadmap for the mini-project: https://github.com/Extra-lightwill/sql-demo-fork-rfs.