App engine muddles folder structure

78 views
Skip to first unread message

miki haiat

unread,
Jul 3, 2016, 7:42:27 AM7/3/16
to google-appengine-go
Hi , 
I having a difficulty to understand  what is the correct way to create multiple muddles application . 

Lets say i have a TO DO app

-Root 
  - Models
     User.go
-Services 
  -GetUser
   logic.go
    getUsr.yaml 
 -DelUser
   logic.go
   deltUsr.yaml  
 
Thnaks,

Miki

Adam Tanner

unread,
Jul 3, 2016, 9:42:06 PM7/3/16
to miki haiat, google-appengine-go
Hey Miki,

Just to make sure I understand your question, I think you're asking how best to structure an App Engine app with multiple modules (recently renamed to services). This question comes up quite a bit, especially regarding what to do with shared code (your User model in the example above). There are a few differing opinions about how best to do this, but I'll outline what I've seen work below. :)

Option 1: Don't use services if your app is small

For smaller apps such as your example, or applications with a small number of developers all working on the entire app, I would recommend against prematurely splitting everything into multiple services. It's going to be easier for you to maintain if everything is in one app and you probably won't utilize most of the benefits that decoupling everything provides, but you will incur all of the cost. In this case, your app structure would look something like:

todos
├── app.yaml
├── user_api.go (all actions pertaining to users: delete, retrieve, list, update, etc.)
└── user.go

Option 2: Use services, keep code in single "app" directory with multiple "service" directories, utilize absolute import paths and GOPATH

For larger apps with services that have sufficiently different performance requirements, release requirements, or are owned by different dev teams, it may make sense to use services. In this case, what I've seen developers do is to continue with the code for all services living in the same app directory, but have multiple service directories with their own YAMLs. This is the pattern that the thread you referenced discusses and is basically what you have above. The trick with this is making sure you have GOPATH set up properly so that you can take advantage of using absolute import paths for your shared code.

I'll expand on your example a bit and we'll assume that you've be hugely successful with your todos app, raised your first round of funding, and now you need to add an API, billing support, marketing pages, etc. to get ready for selling to "the enterprise". An example of this pattern might look like:

$GOPATH
└── src
    └── todos
        ├── api
        │   ├── app.yaml (module: api)
        │   └── user_handlers.go (imports "todos/user" for GET/DELETE APIs)
        ├── marketing
        │   ├── app.yaml (module: default)
        │   └── marketing.go (renders HTML for about/contact/marketing blurb, etc.)
        ├── billing
        │   ├── billing.go
        │   ├── app.yaml (module: billing)
        │   └── worker.go (imports "todos/user" to obtain billing information, etc.)
        └── user
            └── user.go (shared code to access user information from Datastore, etc.)


Each of the services can be developed and deployed independently. Assuming your current directory is todos, you can deploy each of the services like so:

    $ goapp deploy api/app.yaml
    $ goapp deploy billing/app.yaml
    $ goapp deploy marketing/app.yaml

Or all of them together like so:

    $ goapp deploy api/app.yaml billing/app.yaml marketing/app.yaml

Hope this helps! Let me know if anything still doesn't make sense and I'll try to clarify further. :)

Adam





--
You received this message because you are subscribed to the Google Groups "google-appengine-go" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengin...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

miki haiat

unread,
Jul 4, 2016, 7:11:16 AM7/4/16
to Adam Tanner, google-appengine-go
This is super helpful  thanks. 
Option 1 is something that i did in the past .
Option 2 is defiantly the way i want to go for this project .
My next issues  that i don`t understand.
  1.  How i handle all the handlers and register my http handlers  one entry point or for each Service .
  2. Should i override my routing with a custom dispatch.yaml.

If you have some code example for my it will be amazing .

Thnaks,

Miki


Reply all
Reply to author
Forward
0 new messages