BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//LaraChat//Events//EN
CALSCALE:GREGORIAN
METHOD:PUBLISH
BEGIN:VEVENT
UID:01a1b1cc-943c-7225-8de6-ebf78037512d@www.larachat.co
DTSTAMP:20261107T172608Z
DTSTART:20200630T110000Z
DTEND:20200630T120000Z
SUMMARY:Database Types & Design first APIs using Stoplight Studio
DESCRIPTION:This month we have Mark Taylor (@willCodeForAle on twitter) Lea
 d Architect at DealTrak\, giving us a talk about all the different databas
 e types available to you as a PHP developer.\n\nWe also have Phil Sturgeon
  (@philsturgeon on twitter) Developer Relations at Stoplight and API guru\
 , giving us a talk about how you can go design first for your APIs using S
 toplight Studio and OpenAPI.\n\n=========\n\nDifferent Types of Database:\
 n\nDescription:\n\nOften Developers will just go with a commonly used rela
 tional database as it’s what they’re already comfortable with\, howeve
 r a relational database can often not be the best tool for the job. My tal
 k introduces you to the options available\, which will help you to choose 
 the best database type for your project’s requirements. Candidates will 
 be Relational\, Key Value Store\, Document\, Wide Column\, Graph and Time 
 Series databases\n\nAbout Mark:\n\nOver far to many years\, Mark has done 
 a mix of design\, development (particularly PHP)\, DevOps\, database admin
 istration and technical architecture. He currently works for DealTrak as t
 heir Lead Architect.\n\n=========\n\nDesign first APIs using Stoplight Stu
 dio:\n\nDescription:\n\nAPI Description Documents (a.k.a "specifications")
  can be used for all sorts of time and money saving things. At this point 
 most developers are aware they can help with docs and have maybe played ar
 ound with mocking\, but they often have this concern about "keeping specs 
 in sync with code".\n\nThis talk walks through using API description docum
 ents for client-side validation (avoid validation hell by telling your cli
 ents how they should handle validation)\, server-side validation in the ap
 plication (stop writing complex validation logic in your ORM model or some
  other awkward place)\, and validation in the API gateway (don't even both
 er wasting application server resources with invalid requests).\n\nMostly 
 talking about OpenAPI and JSON Schema\, as they can do a whole lot more th
 an Protobuf and GraphQL Types.\n\nAbout Phil:\n\nPhil is an API advocate a
 nd openapi advate\, currently working for Stoplight helping them build awe
 some tools for API design and testing. When he isn't planting trees\, ridi
 ng his bike all over the world\, or working on API specifications you can 
 often find him writing a book or two.\n\n=========\n\nJoin us on Slack\, o
 ur online community: https://www.phpsouthwales.uk/slack\n\nThank you to ou
 r sponsors:\n\n- Lexis Nexis\n- Twilio\n- Techire\n- TYPO3\n\nWe *always* 
 need more speakers! Volunteer to speak or request a topic: [masked] or #sp
 eaking in Slack\n\nhttps://www.larachat.co/meetings/database-types-design-
 first-apis-using-stoplight-studio
URL:https://www.larachat.co/meetings/database-types-design-first-apis-using
 -stoplight-studio
END:VEVENT
END:VCALENDAR
