Thanks for the heads up!
All right, maybe multiplayer Tetris or something? 
zenw0lf
zenw0lf
zenw0lf
Thanks everyone for your participation!
So, I’ll be working on a GraphQL API tutorial over the coming weeks on my spare time.
Once it’s done I’ll post a link on this forum to get some feedback.
1
thiagovarela
jung-hunsoo
zenw0lf
Hello!
Long time no see.
I have a small update for this tutorial.
I added a Simple VPS deployment section to it.
Also updated the code, and removed a couple of warnings that were in there.
I’d appreciate any feedback you might have.
Cheers!
2
denym
Hey @zenw0lf
short question. After reading couple of tutorials and blogposts about phoenix and APIs I come across the data nesting of the json responses.
like
%{
data: %{
user: %{
id: user.id,
email: user.email
}
}
}
All the guide doe that and looks to me highly unusual since from the js side I always have to access the payload via response.data.data;. Even in your tests you have to access it via = json_response(conn, 200)["data"]. Wouldn’t it make more sense to have it nested based on the object type like %{ user: %{ ...
best regards
denym_
1
LostKobrakai
Iirc there are/were security problems with browsers, which could be circumvented by always sending data as part of a top level object.
1
zenw0lf
It’s just good practice to not return top level arrays as the result for a request. At some point it was a vulnerability like explained here: Anatomy of a Subtle JSON Vulnerability | You’ve Been Haacked
But, nowadays, I just use it that way because sometimes I add extra properties to the response like this:
{
data: [ ... ],
metadata: { current_page:2, total_pages: 10 }
}
So it’s good to keep separate your data from other attributes you might want in the response.
And regarding the res.data.data access, I prefer to not have a customized name for the data attribute. Although it sounds good in principle, in the long run is better to have a uniform way to access what you need from the response.
In any case you should be able to instruct your HTTP client to unwrap what you want for you on every request. For example, I have this setup for Axios for interacting with a Phoenix JSON API:
import axios from 'axios'
const baseDataService = axios.create({
baseURL: 'http://localhost:4000/api/',
headers: {
'Accept': 'application/json'/* ,
'Content-Type': 'application/json;charset=UTF-8' */
// Seems like that's the type Axios sends by default
},
withCredentials: true
})
baseDataService.interceptors.response.use(
function (response) {
// Unwrap and return the data property
return response.data
// This is desired unless you have a special need for any of the
// other root properties:
// config, headers, request, status, statusText
},
function (error) {
if (error.response) {
return Promise.reject(error.response)
} else {
return Promise.reject(error)
}
}
)
export default baseDataService
So, on my requests, assuming I’m returning data and metadata (like in the example above) I do something like this:
userService
.all()
.then(res => console.log(res.data, res.metadata))
2
spinlock99
I think™ JWT is part of the json-api spec. I’d recommend using it regardless as token based auth is much nicer for an api than session based auth.
0