Comments (7)
I can get behind the argument that SchemaConfiguration
should be scoped within the namespace and the fact that it isn't right now with embeddedInTarget
could be seen as a bug. In my preliminary testing we can scope it within the enum namespace without any adverse effect to the cache key functionality.
Xcodes inability to handle files of the same name, within the same target even though they're in different paths, is an Xcode bug and best fixed there. In short I'm saying that filename prefixing with the schema namespace is not a change we're willing to make. The codegen templating engine is fairly easy to understand so you should be able to adapt the source to that style of filename output if you really want to go down that path.
from apollo-ios.
@michaelloo - I've created two issues that could alleviate the issues you're experiencing:
We haven't prioritized them into our projected work and they should be relatively easy to get done. If you are interested in collaborating on them we'd be happy to provide design/implementation review.
from apollo-ios.
Thanks for the feature request @michaelloo. Apollo iOS is not designed to be used directly with multiple schemas in the same target and I don't believe this is a change we're likely to make in the future. That said, there are a few ways forward:
- Apollo Federation - this is the industry standard on how to combine multiple GraphQL APIs into a single federated graph. The benefit with this approach is that your client works with a single GraphQL schema and the router handles the subgraph complexity.
- Configure the different schemas into different targets/packages, as we've discussed in the other issue. This unfortunately means managing multiple codegen configurations and doing multiple separate codegen executions. The different targets/packages will get around Xcode limitations with duplicate schema configuration filenames. We also believe this leads to better isolation and separation of concerns.
At time of writing, we have to further split our frameworks in order to avoid filename and namespace conflicts (see #3354 (comment)).
This is not ideal as it requires a large refactoring piece in order for us to keep using Apollo
It's just the generated schema modules that need to be separate, so you may not need to split your frameworks. Your frameworks would then need to gain new dependencies on those separate schema modules, and where you are calling the various APIs currently would need to use the new module namespace.
- Could the schemaNamespace property be used as a prefix to all the generated files?
With the above solutions this becomes a project workflow concern; wanting to generate multiple separate GraphQL schemas into a single target. Apollo iOS is not designed for this use case.
- There are some files that are not added to the enum generated via schemaNamespace like SchemaConfiguration, can they be in the created namespace as well?
It looks like the SchemaConfiguration
enum is the only piece of generated code that is not scoped within the generated namespace when choosing embeddedInTarget
as the schema module output type. I'm not 100% sure why not but I'll take investigate further.
from apollo-ios.
Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better.
from apollo-ios.
Hi @calvincestari, i'll look into the Apollo Federation. In the meantime let me share some more context on our setup.
We have a large codebase with over 50 developers contributing to it. It was divided into modules to make ownership of certain areas clearer. We have local development pods for each of those feature areas. See a simplified example diagram here of what it looked like with 0.52.0:
graph LR
App --> Module1
App --> Module2
Module1_API_Models_For_FooAPI -- generated for --> FooAPI
Module2_API_Models_For_FooAPI -- generated for --> FooAPI
Module2_API_Models_For_BarAPI -- generated for --> BarAPI
subgraph podpsecs
Module1
Module2
end
subgraph Module1
Module1_API_Models_For_FooAPI
end
subgraph Module2
Module2_API_Models_For_FooAPI
Module2_API_Models_For_BarAPI
end
subgraph APIs
FooAPI
BarAPI
end
Whilst we we generated the models for the same endpoint in 2 different modules, it was ok because:
- They are generated code
- The modules are owned by different team who updates them based on their needs (independence)
When we updated to 1.9.0, we've had to adjust some of our modules as they were requesting from different APIs:
graph LR
App --> Module1
App --> Module2
Module1_API_Models_For_FooAPI -- generated for --> FooAPI
Module2_API_Models_For_FooAPI -- generated for --> FooAPI
Module2_API_Models_For_BarAPI -- generated for --> BarAPI
Module2 --> Module2_API_Models_For_BarAPI
subgraph podpsecs
Module1
Module2
Module2_API_Models_For_BarAPI
end
subgraph Module1
Module1_API_Models_For_FooAPI
end
subgraph Module2
Module2_API_Models_For_FooAPI
end
subgraph APIs
FooAPI
BarAPI
end
Whilst this works, it doesnt feel right as we:
- expose a new podspec for
Module2_API_Models_For_BarAPI
, so every other podspecs can now also suddenly depend on this module that was only intended to be used by one module - we could expose a
Models_For_FooAPI
since its being used by 2 different modules, but we then have issues with who maintains and owns this module
We've decided to swallow these for now, but it isn't ideal for the way our company operates, as we prefer to have one team owning each modules to reduce the amount of synchronisation needed and communication overhead (especially if you multiply this setup to have about 15 modules)
From a quick read at Apollo Federation, whilst it will indeed support the feature I am requesting here, I am not sure it will support our immediate needs (as it means creating another system in our architecture to host the Router
).
We might run into "ownership" of how the generated code is updated, given I assume we'll need to create another module in with the generated code from all the different APIs, which becomes a single point of failure.
We prefer automy and independent delivery of features as much as possible so this might not work for us (unless i misunderstand how this will work on the client side)
from apollo-ios.
- There are some files that are not added to the enum generated via schemaNamespace like SchemaConfiguration, can they be in the created namespace as well?
It looks like the SchemaConfiguration enum is the only piece of generated code that is not scoped within the generated namespace when choosing embeddedInTarget as the schema module output type. I'm not 100% sure why not but I'll take investigate further.
Is this the only piece of the puzzle preventing you from using your preferred module configuration in diagram 1?
from apollo-ios.
There is:
SchemaConfiguration
file and struct name needing a rename / prefixSchemaMetadata
file name needs a rename / prefix- Some of the contents of
Schema/Objects
file name needs a rename / prefix, e.g.:Query.graphql.swift
I feel in general it might be safe to prefix the file name with the schema namespace the same way the structs are part of the schema namespace enum for all generated models, that way we will never get a file name conflict. This will be similar to how some of the protocols in SchemaMetadata
are created (e.g.: GQLSchema_SelectionSet
). Although this makes it look more like ObjC naming convention now 😞 . But this will address both this feature request and the other bug request mentioned in #3354
from apollo-ios.
Related Issues (20)
- Custom Scalar | ApolloAPI.JSONDecodingError.couldNotConvert(value: AnyHashable to: Swift.String HOT 5
- How should I continue after handleErrorAsync inside a custom ApolloErrorInterceptor? HOT 5
- Defining a CustomScalarType which is [String:Any] HOT 10
- Deprecate `legacyResponse` and prepare for partial/incremental caching HOT 2
- Custom scalar isn't being respected HOT 7
- @defer issue HOT 8
- Documentation for @import directive. HOT 9
- Add debugDescription api for Apollo generated types
- Circular reference Build Error HOT 6
- Invalid redeclaration of synthesized property '_id' HOT 7
- Split/Hybrid Caching between InMemory and SQL review and thoughts HOT 2
- ID as a custom scalar HOT 6
- Bug: Cache writes of incremental responses uses incorrect parent key (custom cache keys)
- Incorrect PR link in release notes for version 1.11.0 HOT 2
- apollo-ios-cli deprecated --schema-name HOT 2
- Confused about cache behavior HOT 2
- CLI fails to run with 1.12.0 HOT 4
- Response value getting nil HOT 2
- Version mismatch between package and CLI HOT 3
- Pagination: Pager does not provide updates during a refresh HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from apollo-ios.