I'm just starting to explorer GraphQL as an option for my analytic platform API layer.
My UI is mainly built from tables and charts. most of the times the data represents some DB columns grouped by a dimension.
I've found the following article https://www.microsoft.com/developerblog/2017/09/28/data-independent-graphql-using-view-model-based-schemas/ from Microsoft, describing their take on how suck GraphQL schemas should be designed (see below).
type Query {
channels(source: String!, query:String!, appId:String!, apiKey:String!): [Channel]
lineCharts(source: String!, query:String!, appId:String!, apiKey:String!, filterKey:String, filterValues:[String]): [LineChart]
pieCharts(source: String!, query:String!, appId:String!, apiKey:String!): [PieChart]
barCharts(source: String!, query:String!, appId:String!, apiKey:String!, filterKey:String, filterValues:[String]): [BarChart]
}
type Channel {
name: String
id: Int
}
type LineChart {
id: String
seriesData : [Series]
}
type PieChart {
id: String
labels: [String]
values: [Int]
}
type BarChart {
id: String
seriesData : [Series]
}
type Series {
label: String
x_values: [String]
y_values: [Int]
}
It seems to me that this design is strict, forcing any new chart to be added to the root Query. How can the schema be more generic, without loosing GraphQL benefits?
You could do something with union types and inline/fragments
union Chart = LineChart | PieChart | BarChart
type Query {
charts(
source: String!
query: String!
appId: String!
apiKey: String!
filterKey: String
filterValues: [String]
): [Chart]
}
Then you can have your charts resolver bring ALL the charts and write your queries like
fragment Identifiers on Chart {
__typename
id
}
query {
charts(...) {
...on LineChart {
...Identifiers
seriesData
}
...on PieChart {
...Identifiers
labels
values
}
...on BarChart {
...Identifiers
seriesData
}
}
}
The Identifiers will provide you with some information about what type you're dealing with and it's id, but you can extend it to whatever you like as long as those fields are common to all types on that union (or you can spread it only on some of the types).
There are 2 ways you can go about if you don't want to bring in all the charts:
Add inline fragments for only the types you want, but the rest will still be there, in the form of empty objects.
Pass another argument to the resolver representing the type/s you want
P.S. You can get as granular as you like, there are also interfaces and input types.
Related
React native is having difficulties parsing JSON three levels deep. The object is structured like so:
data: {
post: {
user1: {
name: "user name"
}
}
}
data.post.user1 works fine and returns an object; however, when I try to get the name parameter react-native throws the following error:
undefined is not an object (evaluating 'data.post.user1.name')
Is this a known issue? I am getting data from response.json in a fetch call. EDIT: Object.keys(data.post.user1) returns the same error.
First, declare it in a variable and then make an object :
const data = {
date:{
post: {
user1: {
name: "user name"
}
}}}
Get the value like this :
<Text>{data.date.post.user1.name}</Text>
I'm working on implementing services compatible with Apollo GraphQL federation; my providing services are written in Lacinia (GraphQL library for Clojure).
I have one service that defines Users:
type User #key(fields: "id") {
id: String!
name: String!
}
type Query {
user_by_id(id:String!) : User
}
schema { query: Query }
and and a second that defines Products and extends Users:
type User #extends #key(fields: "id") {
id: String! #external
favorite_products: [Product]
}
type Product #key(fields: "upc") {
upc: String!
name: String!
price: Int!
}
type Query {
product_by_upc(upc: String!) : Product
}
schema { query: Query }
When I execute a query that spans services:
{
user_by_id(id: "me") {
id
name
favorite_products {
upc
name
price
}
}
}
I get a failure; the following request is sent to the products service:
INFO products.server - {:query "query($representations:[_Any!]!){_entities(representations:$representations){...on User{favorite_products{upc name price}}}}", :vars {:representations [{:__typename "User", :id "me"}]}, :line 52}
and that fails, because the products service shouldn't, as far as I know, have to provide the equivalent of __resolveReference for type User (which it extends); just type Product.
This is very unclear in the documentation and I'll experiment with providing a kind of stub reference resolver in Product for stubs of User.
Yes, indeed, you must provide the __resolveReference (or equivalent) for each type the service schema extends. In retrospect, it makes sense, as it provides the "kernel" of a raw value to be passed down the resolver tree.
I want to achieve automatic serialization/deserialization of JSON request/response body for NestJS controllers, to be precise, automatically convert snake_case request body JSON keys to camelCase received at my controller handler and vice versa.
What I found is to use class-transformer's #Expose({ name: 'selling_price' }), as on the example below (I'm using MikroORM):
// recipe.entity.ts
#Entity()
export class Recipe extends BaseEntity {
#Property()
name: string;
#Expose({ name: 'selling_price' })
#Property()
sellingPrice: number;
}
// recipe.controller.ts
#Controller('recipes')
export class RecipeController {
constructor(private readonly service: RecipeService) {}
#Post()
async createOne(#Body() data: Recipe): Promise<Recipe> {
console.log(data);
return this.service.createOne(data);
}
}
// example request body
{
"name": "Recipe 1",
"selling_price": 50000
}
// log on the RecipeController.createOne handler method
{ name: 'Recipe 1',
selling_price: 50000 }
// what I wanted on the log
{ name: 'Recipe 1',
sellingPrice: 50000 }
There can be seen that the #Expose annotation works perfectly, but going further I want to be able to convert it as the attribute's name on the entity: sellingPrice, so I can directly pass the parsed request body to my service and to my repository method this.recipeRepository.create(data). Current condition is the sellingPrice field would be null because there exists the selling_price field instead. If I don't use #Expose, the request JSON would need to be written on camelCase and that's not what I prefer.
I can do DTOs and constructors and assigning fields, but I think that's rather repetitive and I'll have a lot of fields to convert due to my naming preference: snake_case on JSON and database columns and camelCase on all of the JS/TS parts.
Is there a way I can do the trick cleanly? Maybe there's a solution already. Perhaps a global interceptor to convert all snake_case to camel_case but I'm not really sure how to implement one either.
Thanks!
You could use mapResult() method from the ORM, that is responsible for mapping raw db results (so snake_case for you) to entity property names (so camelCase for you):
const meta = em.getMetadata().get('Recipe');
const data = {
name: 'Recipe 1',
selling_price: 50000,
};
const res = em.getDriver().mapResult(data, meta);
console.log(res); // dumps `{ name: 'Recipe 1', sellingPrice: 50000 }`
This method operates based on the entity metadata, changing keys from fieldName (which defaults to the value based on selected naming strategy).
How should I proceed when I want to generate table from list of lists which contains only strings(ex. data from csv). Names of columns don't matter. From all examples provided I saw only binding table items to specific model(which doesn't fit there as I have unknown number and names of columns).
If you already know the column names and data type, I would suggest to hard code that. If you know nothing about the format and simply want to create a TableView with completely dynamic columns, you can use the index in the csv data as an extractor to create StringProperty values for your data:
class MyView : View() {
val data = FXCollections.observableArrayList<List<String>>()
val csvController: CsvController by inject()
init {
runAsync {
csvController.loadData()
} ui { entries ->
// Generate columns based on the first row
entries.first().forEachIndexed { colIndex, name ->
root.column(name, String::class) {
value { row ->
SimpleStringProperty(row.value[colIndex])
}
}
}
// Assign the extracted entries to our list, skip first row
data.setAll(entries.drop(1))
}
}
override val root = tableview(data)
}
class CsvController : Controller() {
// Load data from CSV file here, we'll use som static data
// where the first row is the headers
fun loadData() = listOf(
listOf("Name", "Age"),
listOf("John", "42"),
listOf("Jane", "24")
)
}
This approach would only be good for visualizing the data in a CSV file. If you need to edit or manipulate the data, knowledge of the data types up front would yield a less flimsy application IMO :)
I'm trying to create a large object whose values are limited to only 3 types: Texture, Geometry, Script
My object would look something like this:
var assets: Assets = {
sky: <Texture>,
ground: <Texture>,
city: <Geometry>,
people: <Script>,
cars: <Script>,
sun: <Circle> // <--This should fail because it's not one of the 3 types
//...
}
How can I declare the Assets interface so the value in each key-value pair is limited to these 3 types? I tried starting with:
interface Assets{
key: Texture | Geometry | Script;
}
but then it breaks when I assign
this.assets = {sky: new Texture()}
Because it's expecting only key instead of sky. Is there any way of achieving this without nesting objects within objects?
How about:
type Assets = {
[key: string]: Texture | Geometry | Script;
}
That type will allow for string keys and values of one of the types you requested.
More on the subject: Indexable Types