Hello World!
\n \n \"\"\"\n\nNotice that there is nothing specific about the source that will eventually invoke\nthis lambda function. This codeblock can be used to handle a request either\nfrom the API Gateway or from an ALB.\n\n.. _`target of an ALB`: https://aws.amazon.com/blogs/networking-and-content-delivery/lambda-functions-as-targets-for-application-load-balancers/\n\n\nRequest Object\n**************\nAny view has access to the **app.request** instance as a way to retrieve the general\ninformation of a request. The fields of this object include the query parameters,\nthe path parameters, headers, payload... Given that different sources might have\na set of additional fields, minik will store a copy of the original event in the\n**app.request** instance.\n\nFor instance, the API Gateway has the concept of stage variables that is missing\nfrom an event received from the ALB. In this case, the generic app.request instance will\nnot have a field called stage_variables. Instead, minik keeps a copy of the original\nevent and context objects in the request. In this case a developer can access these\nvalues using the app.request.aws_event['StageVariables']. Where the aws_event is\nthe event minik received as the handler of the lambda function.\n\n.. code-block:: python\n\n from minik.core import Minik\n\n app = Minik()\n\n @app.post('/events')\n def post_view():\n # app.request.json_body: The payload of a post request as a JSON object.\n # app.request.aws_event: The raw event sent by a source to the lambda function.\n # app.request.aws_context: The context of the lambda function.\n return {'result': 'complete'}\n\n\nMotivation\n**********\nThe team behind this framework is adopting a very minimal set of features to enhance\nand streamline web development in the serverless space. These were the business\nneeds that encouraged us to build minik:\n\n- Ability to write an API using a familiar (Flask like) syntax using serverless\n services.\n- Flexibility on how to build and deploy lambda functions. I do not want\n my framework to dictate these processes for me. I want to own them!\n- When installing a web framework, I want to get only the framework. I don\u2019t\n want any additional tooling or any additional process-based workflows.\n- When using the microframework I am responsible for the configuration\n required to associate my lambda function to its endpoints.\n\nThe features of this library should be absolutely driven by a very specific\nbusiness need. So far, the minimal approach has been sufficient for our team to\nwrite and expose an API using AWS services.\n\n\nJust the framework\n******************\nThings to be aware of when working using minik:\n\n- When used in your lambda function, you're responsible for including the source\n code of minik in your .zip artifact. For packaging purposes we recommend using\n `Juniper`_.\n- Minik is service agnostic, as a web framework it natively supports requests\n from the API Gateway and an Application Load Balancer (ALB).\n- Unlike other frameworks like Flask or Django, where using the decorator is\n sufficient to define the routes of the web app, in minik, you\u2019re responsible\n for linking a lambda function to the API Gateway. We recommend using a\n `SAM`_ template.\n- Minik does not include a local development server! For testing purposes, you can\n either deploy your lambda to AWS using `sam package` and `sam deploy`. For local\n deployment purposes you can use `sam local`.\n\nQuickstart\n**********\nMinik is just one of the pieces that you need to build serverless APIs. If you\nare curious to learn more about best practices and how to get started with this\nmicroframework, checkout out `getting started