Package: architect.sdk
Architect Python SDKThis is the Python SDK used for brokering connections to microservice dependencies via Architect's deployment platform. If you're unfamiliar with the platform or our deploy tools, please check out Architect.io and ourCLIto get started.SDK DocumentationConnecting to dependenciesimportarchitect.sdkasarchitectmy_dependency=architect.service('my_dependency_name')# Client used to connect to serviceclient=my_dependency.client# Dynamically imported models used for message formatting# Used by protocols supporting code-gen like gRPCdefs=my_dependency.defsRESTThe Architect SDK uses the popular REST client,Requests, to broker communication to downstream REST microservices. The client that is provided is a requestssessionthat is enriched with the proper service location meaning only URIs and HTTP actions need be provided:res=my_dependency.client.get('/resource')res=my_dependency.client.post('/resource',{data})res=my_dependency.client.put('/resource/:resource_id',{data})res=my_dependency.client.delete('/resource/:resource_id')gRPCArchitect handles the code-gen for gRPC services for you. Every time you run$ architect install ..., you'll find relevant gRPC stubs generated and placed inside anarchitect_servicesfolder in your service's root directory. This SDK handles the import of generated model objects for parsing input/output messages as well as the import and enrichment of client code for making calls to dependencies.// service.protosyntax="proto3";packageexample_service;messagePayRequest{int32amount=1;}messagePayResponse{int32output=1;}serviceExample{rpcPay(PayRequest)returns(PayResponse){}}# Model definitions will match message names in the .proto file for the servicepay_req=my_dependency.defs.PayRequest(amount=10)# Client will automatically have methods matching the service definition from# the dependency's .proto file. Response handling matches gRPC documentation.pay_res=my_dependency.client.Pay(pay_req)output=pay_res.outputConnecting to data storesSince there are so many DB clients available, we don't want to choose a default for developers. Instead, the Architect SDK provides easy mechanics to parse credentials provided by the platform:importpsycopg2importarchitect.sdkasarchitect# Key used to cite the datastore must match the key used in your# architect service configdb_config=architect.datastore('primary_db')connection=psycopg2.connect(dbname=db_config.name,user=db_config.username,password=db_config.password,host=db_config.host,port=db_config.port)Events and messagingThe Architect platform also supports pub/sub based communication between services. The primary use-case for this flow would be to allow services to broadcast events for other services to subscribe to without needing to know who the subscribers are.NOTE: As of v0.2.x of the SDK, the only method for publishing/subscribing to events using Architect is via REST (mirroring the function of traditional webhooks). We're actively working on means of supporting queuing systems like RabbitMQ, AWS SQS, and more.Subscribing// architect.json{"subscriptions":{"<service_name>":{"<event_name>":{"uri":"/event/callback","headers":{"x-custom-header":"example"}}}}}The URI used for registration must match a URI on your service:fromflaskimportFlask,requestimportarchitect.sdkasarchitectapp=Flask(__name__)@app.route("/event/callback")defcallback():# Custom event handling hereif__name__=='__main__':app.run(host=os.environ['HOST'],port=os.environ['PORT'])PublishingNOTE: simple publication methods coming soon. For now, you can iterate through
subscribers to submit events.// architect.json{"notifications":["<event_name>"]}fromrequestsimportRequest,Sessionimportarchitect.sdkasarchitect# Iterate through notification subscribers to POST payloadforsubinarchitect.notification('<event_name>').subscriptions:r=requests.post('{}:{}{}'.format(sub.host,sub.port,sub.uri),data={})