Answers.Body: <p>So you can definitely do this... the article <a href="https://nystudio107.com/blog/using-vuejs-graphql-to-make-practical-magic" rel="nofollow noreferrer">Using VueJS + GraphQL to make Practical Magic</a> has a detailed explanation of how to accomplish this using the CraftQL plugin and GraphQL... which I think you may find much nicer to work with than custom Element API endpoint(s).</p>
  
  <p>However you can definitely do it with an Element API endpoint as well. It's just a bit more work, and a bit more in PHP-land.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-10-10T12:43:17.473Z
Answers.LastActivityDate: 2018-10-10T12:43:17.473Z
Answers.UserDisplayName: andrew.welch
Answers.Body: <p>Sounds like you're using craft in 'headless' mode. I've heard about that for drupal, but not for craft. I don't see any reason why it wouldn't work. You get the craft UX for creating and modifying entities, but use node as a proxy and view generator. </p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-10-10T19:09:27.913Z
Answers.Text: Yes, exactly, looks like it could be a nice way to go then. Cheers
Answers.UserDisplayName: nickelman
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-10-10T12:03:38.697Z
Answers.LastActivityDate: 2018-10-10T12:03:38.697Z
Answers.UserDisplayName: mooreds
Body: <p>I really love working with Craft, especially around how easy and user friendly it is. However, I do work with React/Vue and usually I setup a node server/app that will do some routing, render views and so on...</p>
  
  <p>Would it be a good idea to have a setup like this:</p>
  
  <ul>
  <li>Frontend: React / Vue</li>
  <li>Backend: node app that has all my public routes setup, rendering views, server side render React/Vue etc</li>
  <li>Backend no 2: Craft CMS with Element API setup</li>
  </ul>
  
  <p>Example:</p>
  
  <ul>
  <li>User requests /contact/person-1</li>
  <li>The request will be matched in my node app as a valid route</li>
  <li>Node app will make request to the API that has been setup for Craft, fetches the relevant info about Person 1, returns the result to node</li>
  <li>Node app renders the view with the data that was fetched</li>
  </ul>
  
  <p>Is this O.K. or completely nuts? Will it be ineffective or is it a good way to structure it like this when I'm in need for a nice CMS like Craft... ?</p>
  
  <p>Please help me out on finding the best approach!</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-05-15T15:51:04.597Z
Comments.Text: @nicklman I like to know what is the conclusion of this? did you able to work with React, Node Craft and EAPI?
Comments.UserDisplayName: Sameera Thilakasiri
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-05-15T16:11:11.160Z
Comments.Text: Yes. I did it like I describe in my list. In order to get SSR to work, and do the necessary requests before view is rendered I used frontload-connect in my React setup. But if a user navigates to another route after the first route he/she entered, the api request will happen on frontend only, but thats more of how React Router works = it renders the requested route right away. In those cases I just put up a spinner while fetching api data. Does that answer some of your questions?
Comments.UserDisplayName: nickelman
Tags: <structure><plugin-elementapi>
Title: Calling Craft API from node.js
ThreadText: # Calling Craft API from node.js
  
  (Asked by: username_0 on 2018-10-09)
  
  I really love working with Craft, especially around how easy and user friendly it is. However, I do work with React/Vue and usually I setup a node server/app that will do some routing, render views and so on...
  
  Would it be a good idea to have a setup like this:
  
  * Frontend: React / Vue
  * Backend: node app that has all my public routes setup, rendering views, server side render React/Vue etc
  * Backend no 2: Craft CMS with Element API setup
  
  Example:
  
  * User requests /contact/person-1
  * The request will be matched in my node app as a valid route
  * Node app will make request to the API that has been setup for Craft, fetches the relevant info about Person 1, returns the result to node
  * Node app renders the view with the data that was fetched
  
  Is this O.K. or completely nuts? Will it be ineffective or is it a good way to structure it like this when I'm in need for a nice CMS like Craft... ?
  
  Please help me out on finding the best approach!
  
  **Tags:** structure, plugin-elementapi
  
  > **Comments:**
  > **username_1**: @nicklman I like to know what is the conclusion of this? did you able to work with React, Node Craft and EAPI?  
  > **username_0**: Yes. I did it like I describe in my list. In order to get SSR to work, and do the necessary requests before view is rendered I used frontload-connect in my React setup. But if a user navigates to another route after the first route he/she entered, the api request will happen on frontend only, but thats more of how React Router works = it renders the requested route right away. In those cases I just put up a spinner while fetching api data. Does that answer some of your questions?  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2018-10-10. Score: 1 | Accepted answer
  
  So you can definitely do this... the article [Using VueJS + GraphQL to make Practical Magic](https://nystudio107.com/blog/using-vuejs-graphql-to-make-practical-magic) has a detailed explanation of how to accomplish this using the CraftQL plugin and GraphQL... which I think you may find much nicer to work with than custom Element API endpoint(s).
  
  However you can definitely do it with an Element API endpoint as well. It's just a bit more work, and a bit more in PHP-land.
  
  
  ---
  
  ### Answer by username_3 on 2018-10-10. Score: 1
  
  Sounds like you're using craft in 'headless' mode. I've heard about that for drupal, but not for craft. I don't see any reason why it wouldn't work. You get the craft UX for creating and modifying entities, but use node as a proxy and view generator.
  
  > **Comments:**
  > **username_0**: Yes, exactly, looks like it could be a nice way to go then. Cheers  
  
  ---
  
  