iOS app with a backend using Vapor about vapor HOT 7 CLOSED

I solved this problem by adding a podspec a fork of the node repository, which means I could use my deserialization code to generate models client side.

from vapor.

@s0mmer I think this is a difficult question that will start to have more answers as the practice matures alongside other features like the spm. For now, I think there's a few practices that will depend on preference.

Multiple Projects, Shared Library

I personally like working with multiple modules and prefer this approach. Right now though, this can be difficult w/ SPM and requires a bit of extra overhead. For this pattern, one would have a separate repository encompassing the shared code that is imported into the iOS and server-side project manually.

Particularly w/ Server-side projects, there's often a need for a specific folder structure beyond the compiled code. For this reason, I support this as a better option to keep the two separate.

Folder Structure

This approach naturally segments your folder / git structure, so its less of an issue, often this project is named something like Shared, or Core.

Deploy without uploading unneeded iOS specific files

Same answer as above, the server code is naturally segmented, so its not really an issue.

Single Project, Multiple Targets

Similar to how we develop watch apps and iOS projects, we could have a specific target for the server and only add relevant files, likely modeling, mapping, etc.

Folder Structure

Generally includes a folder called Shared or Core

Deploy without uploading unneeded iOS specific files

This is trickier, but possible. At the moment, spm doesn't support iOS, so one might include shared files in the global Sources folder alongside server specific code. In this way, only those files will be built. Depending on how the builds are pulled from .git, the additional Swift files may be pulled.

Disclaimer

Its important to reassert that the concept of client / server is still very immature, and best practices will likely arise from trial and failure. Everything said above is my current opinion at the time of writing, and there are many reasons to use one pattern over another for specific projects and purposes. Hopefully others will add to this conversation.

from vapor.

@marcosgriselli we're still waiting on more integrated support between SwiftPM/iOS before we start making special offerings. Without that, the maintenance overhead is too much for us to be able to confidently support at the moment 👍

This is something that we really want to have, and it's a priority for us once the capabilities are there.

from vapor.

If anyone else comes across this, I was having a similar discussion with a co-worker and we had the idea of implementing a Model class in the iOS app so that Vapor's model swift files could be included in both projects (app and backend) but the underlying Model object would have different implementations (maybe the iOS app would use Realm or something). That way the Model's swift file can be "shared" source code wise and both project would have the same model data properties (but possibly different database implementations.

Just an idea, haven't tried it yet.

from vapor.

+1 any news on this?

from vapor.

I've created a Swift framework and was able to get it working with Vapor. Seems like you have to use the Mac target with Vapor, not iOS. But since you'd only want to share model objects, you put all shared files into a "Shared" folder than compiles with both targets.

from vapor.

@hhanesand I'd love to see a blog post about that :)

from vapor.