Errata: replace appcfg.py with dev_appserver.py in the command line examples.
On Friday, November 18, 2016 at 1:06:02 PM UTC-5, Adam (Cloud Platform Support) wrote: > > To avoid the locking problem you'll want to create a separate .yaml file > for each service in the same repository, as outlined in 'Configuration > Files <https://cloud.google.com/appengine/docs/python/configuration-files>', > and load all modules with the same dev_appserver.py instance. The default > service .yaml doesn't have to be called 'app.yaml', but it does have to > have either 'service: default' (or 'module: default', but 'service' is > preferred) or have no service parameter specified. > > You do not need to have the project name embedded in the service name > (there's no need to repeat information). An example structure might look > like this: > > Directory: project-name/default > - app.yaml > * application: 123-<project-name> > * service: default > - main.py > > Directory: project-name/service-customer > - app.yaml > * application: 123-<project-name> > * service: service-customer > - main.py > > These would be launched from the dev server as: > > $ appcfg.py default/app.yaml service/app.yaml <other .yaml files> > > You could also have a flat directory structure, and use a different > filename for the default service: > > $ appcfg.py service-default.yaml service-customer.yaml <other .yaml files> > > On Tuesday, November 15, 2016 at 4:41:54 AM UTC-5, Pim Reijersen wrote: >> >> Hi Adam >> >> Thanks for your quick response! >> >> At the moment I have created a single App Engine project. Every >> module/service has its own repository with an app.yaml file. >> >> <project-name>-service-api >> - app.yaml >> * application: 123-<project-name> >> * module: default >> - main.py >> >> <project-name>-service-customer >> - app.yaml >> * application: 123-<project-name> >> * module: <project-name>-service-customer >> - main.py >> >> >> Using this approach i'm capable of deploying every service independently, >> but it does give some issues with locks on the datastore. Looking at the >> limited resources I can find about this I'm having doubts about if this is >> the correct approach. It looks like people put every service/module in a >> single respository and define all the services/modules in a single >> app.yaml. What would be the correct approach? >> >> >> >> >> >> On Tuesday, 15 November 2016 01:38:19 UTC+1, Adam (Cloud Platform >> Support) wrote: >>> >>> *Microservices:* >>> >>> - You can target a specific service (aka module) directly using the >>> URI scheme <service>.<appid>.appspot.com (or >>> <service>.customdomain.tld). On the development server modules are >>> served from different ports on localhost (eg. 8080 for default, 8081 >>> for the next module). >>> >>> >>> - In both production and on the development server, you can use dispatch >>> rules >>> <https://cloud.google.com/appengine/docs/python/config/dispatchref> to >>> target requests to a specific service based on the URL pattern. >>> >>> >>> - If using the Cloud Endpoints framework, API requests are sent to >>> /_ah/spi/{path-to-method} >>> (v1 >>> <https://cloud.google.com/appengine/docs/python/endpoints/api_server>) >>> or /_ah/api/{path-to-method} (v2 >>> <https://cloud.google.com/endpoints/docs/frameworks/python/api_server>) >>> which can be targeted for routing different API calls with dispatch >>> rules. >>> There is an Endpoints discovery service, but this does not handle >>> routing >>> requests between services. >>> >>> See also 'How Requests are Routed >>> <https://cloud.google.com/appengine/docs/python/how-requests-are-routed> >>> '. >>> >>> *Endpoints:* >>> >>> - Endpoints is intended as a REST API framework. It's technically >>> possible to use it to communicate between services but there are some >>> limitations >>> >>> <https://cloud.google.com/endpoints/docs/frameworks/python/#basic_frameworks_architecture> >>> >>> such as not being able to call an Endpoints API from a task queue or >>> cron >>> job. >>> >>> >>> - A better alternative to Endpoints for inter-service communication >>> is Cloud Pub/Sub. <https://cloud.google.com/pubsub/docs/> >>> >>> See also 'Accessing backend API versions deployed to non-default modules >>> <https://cloud.google.com/appengine/docs/python/endpoints/test_deploy#accessing_backend_api_versions_deployed_to_non-default_modules> >>> '. >>> >>> *Large response/request:* >>> >>> - Storage services such as Memcache >>> <https://cloud.google.com/appengine/docs/python/memcache/>, Datastore >>> <https://cloud.google.com/appengine/docs/python/datastore/> and Cloud >>> Storage <https://cloud.google.com/storage/docs/> are shared across >>> all services and version in a project. It's not necessary to pass data >>> between services using URL endpoints as each service essentially has a >>> fast >>> path to access the same data on the internal network. >>> >>> Let me know if I've missed anything or if you have further questions. >>> >>> On Monday, November 14, 2016 at 10:47:53 AM UTC-5, Pim Reijersen wrote: >>>> >>>> Using the service (aka module) keyword in app.yaml its possible to >>>> create microservices on app engine. >>>> >>>> The reason of this post is to get a better picture of how to setup an >>>> application existing of microservices on the app engine. The application >>>> in >>>> question will receive, store and send a good amount of data. >>>> >>>> >>>> *Microservices* >>>> Microservices communicate with eachother using HTTP requests. How do >>>> you decide where the service can be reached, and how does this translate >>>> to >>>> the development environment. >>>> >>>> 1. Discovery service? Minimal sample or link? >>>> 2. Hardcoded location <service>.<app_id>.appspot.com? and modify >>>> hosts file for local development? >>>> >>>> >>>> *Endpoints* >>>> >>>> 1. Is it a common practice to use the Endpoints feature to develop >>>> an API for internal communication between services? >>>> 1. Another solution would be a webapp >>>> 2. Is it a common practice to use the Endpoints feature to develop >>>> an REST API for users which communicates with the services? >>>> 1. Another solution would be a webapp >>>> >>>> >>>> *Large response/request* >>>> Developing an application which receives/stores/distrubutes a large >>>> data set. Pushing and pulling data is done using a REST API. My concern is >>>> that the data travels to multiple services over the network increasing >>>> bandwith usage. Example; >>>> [user] -> REST API Service -> Data Service -> Datastore >>>> >>>> In a monolith application the data gets processed directly. In a >>>> microservice application the data travels from the user to the API Service >>>> and is then send to the Data Service to be processed. >>>> >>>> 1. Give the Data Service an API which is accessible by the user? >>>> 2. Is this an issue on App Engine cost wise? >>>> >>>> >>>> -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/12c01bf1-f3e9-434a-85d4-1806803fb233%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
